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 E7CE5D44172 for ; Tue, 19 Nov 2024 15:28:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 793D96B00A1; Tue, 19 Nov 2024 10:28:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 743876B00A2; Tue, 19 Nov 2024 10:28:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 614F56B00A3; Tue, 19 Nov 2024 10:28:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 430636B00A1 for ; Tue, 19 Nov 2024 10:28:22 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C01141C6A6C for ; Tue, 19 Nov 2024 15:28:21 +0000 (UTC) X-FDA: 82803224406.21.8D996B7 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf18.hostedemail.com (Postfix) with ESMTP id 86D581C0021 for ; Tue, 19 Nov 2024 15:27:57 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=r2P5RJbB; dmarc=pass (policy=none) header.from=soleen.com; spf=pass (imf18.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732029965; a=rsa-sha256; cv=none; b=QoKlSYKHqtgQDGvmpF+DMUF42ThCrPXjkZ+QBn4ywxWVwBNpLP3v0qea5vNDFipYwz27pD /V5intlfdkgHLU+qviKvpqywoqZmNOcs3JH76iOL43RJD8diEQv7f5qiED8K3Vr2JCzGoE n/rItUeSvM07h8dqgNN+Y7sOPZQFn6U= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=r2P5RJbB; dmarc=pass (policy=none) header.from=soleen.com; spf=pass (imf18.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.179 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=1732029965; 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=8QeEhrDw4c0Kz4tqkiPNGCc/5hs75/QoQULwwP0t36w=; b=fihMIsCi5ZUoxy3r/3ZPPIiK9SbBRAksi/x8poOtoTLSzHKrWYLS5BpcyL/CDpRAX5a4YY jkqknlMzy5PMnzR60YUuyWHKbEpm6A8aLUuZ9nUZomf9CgIzg6IU1mRzKngzOXu2JfQ3BM DwwKiqzGvqtpGpKv05/d7FPKLm7CKzI= Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-46101120e70so42097451cf.1 for ; Tue, 19 Nov 2024 07:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1732030099; x=1732634899; 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=8QeEhrDw4c0Kz4tqkiPNGCc/5hs75/QoQULwwP0t36w=; b=r2P5RJbBkzFx/XuI+fYQjo7xbwlR2SYHCkWcf7zrV1usjQ6gPHKIiSYNReBYl+H6qU JB3oP6d4f/odsmSgPcKQY5cePhTyeJmu2/000krIgJkMUpOO7DB7Z9sXM7xLRvEr/3zO AUhcXJWBC4jrtR+q2g53sRLTwSKJEb1EKsp43wv1SEcN0vIKqU9B/l25dvmZYHKY7uMl Z0pX4GZLAv1vfZFI7PUeUUAfWeh8+tBdNLetb3HvBP2oGsZ/7S8pmJbsW9Ekd9xqTAyx 5f8f6h0FXW13e+nFdXn4POEY3ejt5hiwcdMDv13mK731qo0HbOtmJ9jLq2HcA4TFesS9 UYeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732030099; x=1732634899; 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=8QeEhrDw4c0Kz4tqkiPNGCc/5hs75/QoQULwwP0t36w=; b=ODpdkoP954Ufj36RywNgXQSAcBD+fcTh+WUXyoTtOKweAXkw18NHBsMhEUsOtqh6I+ CKGgtUENXo+kZmlKgl8+ssr7hxcnbkmG5OsK4RTY6znBhG8Q8yTToNmaiFPaB4g6jx/1 T1ArTDIpiCNfNwaSbuJeEraPwZds69J+0ghT71v1/a4flPlW3N/BmQ0rPlML997AkDhH IxDtKuubmO6o2O6zARM7qB1K1zFf5vvc6DpGWNGOxXVvUQukDFbt4Dz/ByFVuUork+Cr quXSqiTGC6MTj05hAxwFjKOmtdj6Fr7CnGpHSmF+5iwBEJD8Jzl2n3DLnBCRXLEfAxKL Zamg== X-Forwarded-Encrypted: i=1; AJvYcCVUBCASimg5uSZbcgEGqFEDv+uhYrYWlEajKlwE1YMqULdliiLCiMnKRQMPrbdgvDjKfMODnHFlzQ==@kvack.org X-Gm-Message-State: AOJu0Yx0pruLI680V0rNE/BoRCacMSqJgzUJS0xO3LRonH5Vi6p5LmLz tokHlU0sW4z02JBvLDvfGk8p6OElfKPrNxjYK9DRZTefyhoJINPcW2nqm4KFVFKbrVTbEyQoVND w8QQ/g9aitUZBrabKBpPOuI48B3ve8W9q8quvTw== X-Google-Smtp-Source: AGHT+IGjLxkk4QkkwK1ciHnchEj5dZmSOY2sOg7ByrWwnCFxlGfZCDeqpXCjhZd11+NESOAZlS8fRqJSchVVDKJHbWo= X-Received: by 2002:a05:622a:17c6:b0:463:5c35:522e with SMTP id d75a77b69052e-46363ea1118mr257015011cf.34.1732030099085; Tue, 19 Nov 2024 07:28:19 -0800 (PST) MIME-Version: 1.0 References: <20241119090740.65768-1-zhengqi.arch@bytedance.com> In-Reply-To: <20241119090740.65768-1-zhengqi.arch@bytedance.com> From: Pasha Tatashin Date: Tue, 19 Nov 2024 10:27:41 -0500 Message-ID: Subject: Re: [PATCH] mm: pgtable: make ptep_clear() non-atomic To: Qi Zheng Cc: tongtiangen@huawei.com, jannh@google.com, lorenzo.stoakes@oracle.com, david@redhat.com, ryan.roberts@arm.com, peterx@redhat.com, jgg@ziepe.ca, muchun.song@linux.dev, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 86D581C0021 X-Stat-Signature: hpwh94nma3p95s3hsz1u8ed9uwtwiaoh X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1732030077-199313 X-HE-Meta: U2FsdGVkX196FeTl0okrVwSsjGsyKhhOy3DMpxyiZeOxlUCs+pTYsAFvBt7uy/dSqf4/j9oPPgAaFlM1VkffL6RwCkSwcCNSUk4fvBRG7tGxaWiVhVW6jfO1X7IArK4V0X0ywxXaJBCfOxPo4rqnyvs5gKHxtuAwaVUrj46R9lDriUH0aQi1CP5MIsQechIxFLQo60jMODM3gFbHNjN8GBJiX5rDXqOgPp5XWGQocYxN+O7jGjRU5P1FFZgoiim612jsWSlsBXZVyNd3KbaauzT12TtDpJr7fAIZl7diMai8XrwCKgmJsKliKAr+5uBX3h6ixUBfM/1+B+izld6vGD/OppdE8GrHCd0PZwDMyv6A2cpmXVVXcgq034ijx3/2e6Si1oL/l2DiGfH3rO8PgwHsvtRet5LHRaac/yDlnoorDfWakvXCNmeNB4PQQ5qnhkb9jHBLWfzMYHCkjYTpKREAysxdEXCTIOQfM4DFzChkj7+K1DaXqhGsmrxCFe26EdSLKyat4743OTBz006vQTz0d+W9ppmQIt7EARpA+xpMUzpx64+2SWM3LzMSXEA6BcBlV/EMtjX3uTn0aGue2nJ7Vr5oNjAjBHHVGsaMQWCi4Sg+JVxwey2cGyxAKh3+jWnL+US+NyIYzXclJNP0xNCINis1zbeKY8NTKIw6xLa1BCxXJ/gdy/oIGpTQuxs7f/tozh+ZUDoxY6C7OvZ47PfxLsJmMARvLMGvKtrln8iGqdRxHYTjyB7cSYuTgsjObNmGrR+VXRANKYgDBB01CSBghmqc0+KF02tZRH45/ozF9Gdq1HzKsLE0NacrtfHTV3tFRxulJs1XIca/DcwMQzYxxVKfTNWtQ/KJq2LoKES1Yn2UGHMIujSDuI6LNssQR3fzIeVjx7HGs07ENnAze7aZX71FpgFmSJ5i7gHF2gdLs0O2ZDxUqL5QYNCRkodDzgkJBAIq+KDcxrtfRAh Yru1S2T0 GHxvwm+W2VuhkEz6LoSTBjKgpCYpYUDkunfp93E60Y4As0q933QojpGpeJAQZej4aweft2dhjnoGd0rqjf06I0bK8Jh0i+75kFE8URaX8zskidtu8ooyJKOxxvk9Hsl0qADWdlhVMsIkJlhERNYMgaXvmo8rs02oEonc/FOR1uGqXkTJ7x6t4Fno8V2VboPgvR6T4ABfKqDP15x4Yl/HlV1T9H9gGKfXvOWobLV2cCCufcIllM+i3XW1eRPHZLSkUoUFiAxdlKW1bOYXHWJj20ouM6TkgUxKVKX2IJGwAgAftlQX36vd2dFk6NHsHPDiZW9vO8nWqSOfK7MjyJwOmSc+EAlndk/YN1ge+AUgK5a27dNMLAAC+sYCfvvRq+cpcrA8f X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Tue, Nov 19, 2024 at 4:10=E2=80=AFAM Qi Zheng wrote: > > In the generic ptep_get_and_clear() implementation, it is just a simple > combination of ptep_get() and pte_clear(). But for some architectures > (such as x86 and arm64, etc), the hardware will modify the A/D bits of th= e > page table entry, so the ptep_get_and_clear() needs to be overwritten > and implemented as an atomic operation to avoid contention, which has a > performance cost. > > The commit d283d422c6c4 ("x86: mm: add x86_64 support for page table > check") adds the ptep_clear() on the x86, and makes it call > ptep_get_and_clear() when CONFIG_PAGE_TABLE_CHECK is enabled. The page > table check feature does not actually care about the A/D bits, so only > ptep_get() + pte_clear() should be called. But considering that the page > table check is a debug option, this should not have much of an impact. > > But then the commit de8c8e52836d ("mm: page_table_check: add hooks to > public helpers") changed ptep_clear() to unconditionally call > ptep_get_and_clear(), so that the CONFIG_PAGE_TABLE_CHECK check can be > put into the page table check stubs (in include/linux/page_table_check.h)= . > This also cause performance loss to the kernel without > CONFIG_PAGE_TABLE_CHECK enabled, which doesn't make sense. > > Currently ptep_clear() is only used in debug code and in khugepaged > collapse paths, which are fairly expensive. So the cost of an extra atomi= c > RMW operation does not matter. But this may be used for other paths in th= e > future. After all, for the present pte entry, we need to call ptep_clear(= ) > instead of pte_clear() to ensure that PAGE_TABLE_CHECK works properly. > > So to be more precise, just calling ptep_get() and pte_clear() in the > ptep_clear(). > > Signed-off-by: Qi Zheng > --- > include/linux/pgtable.h | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h > index adef9d6e9b1ba..e59decd22e1cb 100644 > --- a/include/linux/pgtable.h > +++ b/include/linux/pgtable.h > @@ -533,7 +533,10 @@ static inline void clear_young_dirty_ptes(struct vm_= area_struct *vma, > static inline void ptep_clear(struct mm_struct *mm, unsigned long addr, > pte_t *ptep) > { > - ptep_get_and_clear(mm, addr, ptep); > + pte_t pte =3D ptep_get(ptep); > + > + pte_clear(mm, addr, ptep); > + page_table_check_pte_clear(mm, pte); > } Reviewed-by: Pasha Tatashin Thanks, Pasha