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 77A3FD44171 for ; Wed, 20 Nov 2024 02:14:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 694AF6B007B; Tue, 19 Nov 2024 21:14:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 644846B0083; Tue, 19 Nov 2024 21:14:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50C066B0085; Tue, 19 Nov 2024 21:14:26 -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 33EF96B007B for ; Tue, 19 Nov 2024 21:14:26 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 964F91C7036 for ; Wed, 20 Nov 2024 02:14:25 +0000 (UTC) X-FDA: 82804851486.13.C2FB6BC Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) by imf18.hostedemail.com (Postfix) with ESMTP id 63C781C000B for ; Wed, 20 Nov 2024 02:13:59 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ZVFp3ufX; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf18.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732068679; a=rsa-sha256; cv=none; b=aSqhCzDGf3t2RUEPNYC8c1cx9ONGcq6JURlRU4U5+qKsQoSPcbUz4N4R6pgLqy8arYKZuo 7aHiyyl8pt/1Uy2eTirMxvbGHwdhqFZgdksxdJaD5eyjlxTdp93GNLeBcurHKyFe+xSqxJ 34J/DXgmuO3SW1oy5tCqsN6UL500Ymo= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ZVFp3ufX; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf18.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732068679; 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=pZE9XS2nS1P9CSr00f4qjxs7S+FpZe2i+/rEGi6QgV8=; b=6bUUsSKGvLasJ3rB+XhOJC0J5DeEjEU02sa2VstC3AAwCajJFvnPY/UdbzeBkZQ5aDRZSA PA06NWA17QV/fPbCLcyR/THYPCkpltQ1WZU0Py37BR/3ImlGvRrP3iGSTlzDKapBQ18atS cFjnIRsP4vttRCQnRXMUoazoKsDFIp0= Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1732068860; h=from:from: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; bh=pZE9XS2nS1P9CSr00f4qjxs7S+FpZe2i+/rEGi6QgV8=; b=ZVFp3ufXSYcmcijvZx7n/JQU74JqYc0cBkoW1y+Me2Aq41VLQOOV9vgDjMQzLPPxgVbnau IQ+wezzWUH13AwVKHlkKdYbpWImeuEzAAOzcAhR+OeVSpBZejcmyNTZzuioEL6woK/u5QX euM28gjcSYwQxAachvsnoJH1XMkz+nY= Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\)) Subject: Re: [PATCH] mm: pgtable: make ptep_clear() non-atomic X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <20241119090740.65768-1-zhengqi.arch@bytedance.com> Date: Wed, 20 Nov 2024 10:13:21 +0800 Cc: pasha.tatashin@soleen.com, tongtiangen@huawei.com, jannh@google.com, lorenzo.stoakes@oracle.com, david@redhat.com, ryan.roberts@arm.com, peterx@redhat.com, jgg@ziepe.ca, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Transfer-Encoding: 7bit Message-Id: References: <20241119090740.65768-1-zhengqi.arch@bytedance.com> To: Qi Zheng X-Migadu-Flow: FLOW_OUT X-Stat-Signature: px3odfag9qh5fiizphx56pyoj5t4rtat X-Rspamd-Queue-Id: 63C781C000B X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1732068839-397264 X-HE-Meta: U2FsdGVkX194EThf+y3Or3LDlQgAbpqHIr2/Rt4EizdVQrEARm3kU/wL287GICUbK0nNbEfmDhwNAvJNUnSq+mAYum3C/+uGGlDHostmRraPHOHEEDUyrv27UVCoY7yrMaDZPq1T21aXIIvrLZ5TFOzN+s+uWzCj+TReLqXBEwCC+qipCI3JfIgoyX/+KOxZnYLzzq5hcWEB37JUpGMwJweqI231r6N6dG/nRvWxdrGOjTPFUH8dhWHOaYp3drfmBvqG4h1MhnDDvgc/u72Y3g3eU0WZ7AIHXfhld1A9SCcPAiW7OAqANkRx/NsudDZGmEVUHCEX/wH3/kP23NDUQZN7IVTGW+TBustRi/LWBOVnRD3W6QXw8V7diVrxAgA/Ki5PebKhxC7cVSCk1WKfAbEKf5JsoWmei9X4bgGZCZMKen//8yiFipjHD0R3Y5Pe7DFqQ9M+7NuxDOojsFZ28puOerfPFOdMhEfoJVesWdtBPp5Xarf9k9zB8T1aFF5P3UkS7Fu8srE9ecAIwA/zAiwf+Bxas6hMBPub8b+Es01O7SDPvQQ0Wx1DL74sDh1RnZrm6hszvwyAMd81X59phB17/xe+AlQ49RI11Iz990aV7JtxCWi+NcK7vA6NmAB1YvkJ7dPlLF2z/Zn2i384jMV7U29M/7BaYLeVzyu7wbDldnLYGKH1mLRWPOyQ82JhkDLNNQaLUye+3zQQ5LzFmS6xvfzIn3OBmey92f+WcpmmIa7BOfv/bt56f2uIxaCEHiTCZflIeiALUeeuTZIuIDnA961NFHIJKewZSPl+rvZxIyOJJ9ZELqcURZeOOYo7RzRqkFd9XBHRS/JPJ9ajc7NkL/47CFgV7vk82LHa1xIzhQu9+a4CjDdeMreIljz1XTAQyV6kGcOKCBlrmJ/3XWCAueJpoxqiUH6FgPHsalrSgEmPeB1+O0hyRO5wmVcJ7nzk3+v3C5scUFeBR4e o094FzNO KlKwxIZUUryZsL0Z8e9gx8sesj2LeYTeE1WjSVVyiB/6C692hLNm/9gSwpwDPlOfkxaP5bwZy5U8bPnXH8jFXyxq4XTgAxRV/xGzK98R3+afCt8+yXghcSpymRzmUH0LxrKIjhPkTnzhlDYIc5xqy6eH7tP2ONy9Dew6sWWXJ+p+GL0fpoBdbjdjb1Jmvx2R8nUh1ieKKFmb4gLzxw2kgrSOy0bEHYuLgfteQEKBPlIK8esBdR3FX27XI8uHUpfvGf6PSBclVvU8CiWUGEYPhGaoo4g== 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 Nov 19, 2024, at 17:07, 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 the > 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 atomic > RMW operation does not matter. But this may be used for other paths in the > 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 Reviewed-by: Muchun Song