From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A4D97C35274 for ; Thu, 21 Dec 2023 05:14:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E96AE6B006E; Thu, 21 Dec 2023 00:14:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E1F126B0080; Thu, 21 Dec 2023 00:14:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C72776B007E; Thu, 21 Dec 2023 00:14:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B310B6B006E for ; Thu, 21 Dec 2023 00:14:24 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 78FEE1601F7 for ; Thu, 21 Dec 2023 05:14:24 +0000 (UTC) X-FDA: 81589659648.02.95BA823 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf04.hostedemail.com (Postfix) with ESMTP id A056C40005 for ; Thu, 21 Dec 2023 05:14:22 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=SdZoIGHf; dmarc=none; spf=pass (imf04.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703135662; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=MPm674rXSCwxQgD/8kQz5c0fP5ST0f+zOSOq7hzl6LU=; b=3FcFbDAg6IaB9G8JOrGVuUBNtvGQu8oY9kjeYN6Z75B1FDtHm8G+F+VIPEBi1hB0XwW6u4 35eH6vn5CYKVpCV4esR0ZYQ0c+1Nz2TvVCey5KZF/zYfZRxXXMpFnPzixOFawiWKf1FaeH CXQPHj6RUdyFGbjmeipqvrtKL66muyA= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=SdZoIGHf; dmarc=none; spf=pass (imf04.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703135662; a=rsa-sha256; cv=none; b=HCQ/5PnA8DISzhPJ24vKfCv4PgvuP6FQO0CsfBxh9PU+nTGKi4N2rjfDjDvvsiHz0Xpjky fEBVWtjaR64WC2x2q66kiwXwC+EXkKWIpkLEA0r94p7U9QAmgvoBE70uH1Q3CHUyIUhWHt hbfExNw0cfcwa8Rxdd3SmXSPMKp/6Pc= Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-425cbee636fso3261681cf.0 for ; Wed, 20 Dec 2023 21:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1703135661; x=1703740461; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MPm674rXSCwxQgD/8kQz5c0fP5ST0f+zOSOq7hzl6LU=; b=SdZoIGHfhgFZjwvlYb0IAJiET7EyJs9hcP+AHbR6n8umNYfenXRUcjG3FvoWjIKsBr BNqFsuZhUfofCD9GEi+CzJ8gvzwIXoD/kD7qZHp95qVssDkuaCZcIUHmd9VzWYjA9Sxo qRk6CM/RmxI8/tICQpKZ83sqEtaI214hg7tdHIyVuGIhGTOatJLyLJvIdUNnvXOt+tKs 3luBvmAq+hpLlvBszvaIy0+7aZpJJbbGh6BN8Gl+4Y+0Le6ixGv9SAloq1azzs41cfgh dVaBTodEmS0TA08Gb1YZNCZC4ADy5NlVKWvnZjXj2XFSVwTJsRZGOhWrkH10tFUJFhoO YVhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703135662; x=1703740462; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MPm674rXSCwxQgD/8kQz5c0fP5ST0f+zOSOq7hzl6LU=; b=VRWZ7yOlACucG31Sj86ultIAWwNHaIZlaAZHvWcxxnH6oDJj1mUSQysYV54rBTX1HP fD6ir/5+D+qrLn/KhZyAnNJrJZs8bXJer2y7DEDDQFhNNixf4zpKFeKZQpUNtDZ9PGja bQzxfbKXCgEmc67TcJuwg8rdw0CMCeURtwrB6ExNXvxMtXusG35HhAcn1hBCHujX65IZ 9rwsl3vBUjVLL6THDxS+qkqVxsROUWRtdgbQRb6Hec0tNU4CrmSzrITfG+/4Kyl/bdFL sQzxGIMJMGLO2Sr/wt+4hSxyimBIaKzdVWXlkJsGwZIsBzpZ9PhnfOOZnUl7huj3yji7 w89A== X-Gm-Message-State: AOJu0YykmmoQO5aksleStPO4JaPP2NR+K5Qdw8uYNQIgUUwv86oo/utN iBb1wXpCkwLvNRS11lKcX3iLNjqLMu7AzRrLxzJXqQ== X-Google-Smtp-Source: AGHT+IFIF1kvdOQPV+kJwz+HvYp+BsGI4zVt5IRuyYg3yYDH4YeYNF4H2ORzJCxlpNLtqey20DUdsVzsI8tO4OwIYkI= X-Received: by 2002:ac8:5747:0:b0:412:14a8:24c8 with SMTP id 7-20020ac85747000000b0041214a824c8mr31395413qtx.8.1703135661768; Wed, 20 Dec 2023 21:14:21 -0800 (PST) MIME-Version: 1.0 References: <20231221031915.619337-1-pasha.tatashin@soleen.com> In-Reply-To: From: Pasha Tatashin Date: Thu, 21 Dec 2023 00:13:45 -0500 Message-ID: Subject: Re: [RFC 0/3] iommu/intel: Free empty page tables on unmaps To: Matthew Wilcox Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, rientjes@google.com, dwmw2@infradead.org, baolu.lu@linux.intel.com, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, iommu@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: p9gzp1froscitrpb63ns5378378grak1 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A056C40005 X-HE-Tag: 1703135662-698108 X-HE-Meta: U2FsdGVkX19Jv8rfzpuROAv+GIlqOamijkv+RczSfsDR7rtVFAd4W5i8M8ut9ANnDw8k4pYlB7a5oS3tk/6UuR1EHAaypgWHceVqghsQNIFJgsJrvTPYBZ0qDCi0gk3hV1urTjwoxntYNRV8O/7Tqyw03RWjzv0yO7sS9LKgw7SQ4tW8Txi03SlrZvsX6QahDL/fckuTUYH4Y3fAavOGj2OXsMUOxjijiYoV9HWvLwHCzetBGRcb5AWGXwm4eFBfFgIGTSBbmIb6Gzt7WljzHYY1shW0rPHbyLbYfGI4Z1FJm+qO5/BE4Djiyw3AOlcJecYMAZEsnrk7eQUjNhzrMktwmgf2XSczfhjCVGQNw8uKO2/hwCHXkdzIUtSUoj+tIGVWc+gEp6i2NNbr4hj5pNCDbhVi9HcYlx+iXIYpdyZ90hSa7JPyV4FgupnKT5LcE8sefekU10wQLqikdRCZSUEsKWkZEW45aQ4OHLiJnYYERlE6HDOp5hAAbJcq3xMfMvz6pVNPpMBMre2OPI3VHvap8j7lOsDH1R5mfjOlbt/dLdL8dhUl9hnHwO84aekYVkT1Vkm+Gspe5In4Q7R3TFlotsTYUDIVm4WoZn+eCegrqIQhTJSRexr6sdIXjHEVJWP/kAuSiM/WhJYwGwmm4hHCS6ZI0Er7qT02JGKqzUO5ZnkIJshuC4dxcKDvoKqHrio7xUwomBUpJPYDY0nVuu6Wopp3UA6AKK93GP2rlSVeiMZBGb5Z83uNPZCOJkubCrPrEO/tylMl4fUnTyjPHxCiPgrAruI1YEymIz3hRXCCwU7CKqxAgM4kmAbM/hEHJWRmuyJE4sN+CdoYkiUXN8zSU+9fig9FnWJFLzNHSO9lMMbqwl84E8YL/mHP8BKlb/bf0mPaWVf1nHJ+zxzBgQbR2IPdbOpl7B+bfeaxp+/eU+TkPP1/y2Kprf1PBZz3vunDc6MaKdHdptkWWGo gwuCCF5w 2ec3D4aoQZAXgNQAPskQIGM8vd7olk+Hw4XFx3c+UD40z+eecxtYh8r3F3Oeefq4rCVl0qkl2vkXDqevp7DGBiNvHwYqP6AD606JdjfGDViFCeixDthFEVY3Y/nUXOloffWpRWnLiNydTLCP4MfcJ66fbPY+xUDqfFPIa0B2/YocsxNZ+tqRERfC58cC7XrPUEWk8zJoj5osX5JOVKx8RIxTja+77/o2exwD59gmsGlb4ldqlFG1SZhczjjK5JjN++mkzPbf17T+T7sg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000178, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Dec 20, 2023 at 11:16=E2=80=AFPM Matthew Wilcox wrote: > > On Thu, Dec 21, 2023 at 03:19:12AM +0000, Pasha Tatashin wrote: > > This series frees empty page tables on unmaps. It intends to be a > > low overhead feature. > > > > The read-writer lock is used to synchronize page table, but most of > > time the lock is held is reader. It is held as a writer for short > > period of time when unmapping a page that is bigger than the current > > iova request. For all other cases this lock is read-only. > > > > page->refcount is used in order to track number of entries at each page > > table. > > Have I not put enough DANGER signs up around the page refcount? > > * If you want to use the refcount field, it must be used in such a way > * that other CPUs temporarily incrementing and then decrementing the > * refcount does not cause problems. On receiving the page from > * alloc_pages(), the refcount will be positive. > > You can't use refcount for your purpose, and honestly I'm shocked you > haven't seen any of your WARNings trigger. Hi Matthew, Thank you for looking at this. Could you please explain exactly why refcount can't be used like this? After alloc_page() refcount is set to 1, we never reduce it to 0, every new entry in a page table adds 1, so we get up-to 513, that is why I added warn like this: WARN_ON_ONCE(rc > 513 || rc < 2); to dma_set_pte() macro. When refcount =3D=3D 1, we know that the page table is empty, and can be added to a freelist for a delayed freeing. What is wrong with using refcount for a scalable way of keeping the track of number of entries in a iommu page table? Is there a better way that I should use? Thank you, Pasha