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 807A2D4417A for ; Tue, 19 Nov 2024 15:47:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B1F56B00C1; Tue, 19 Nov 2024 10:47:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 162136B00C2; Tue, 19 Nov 2024 10:47:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 029176B00C6; Tue, 19 Nov 2024 10:47:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D24D36B00C1 for ; Tue, 19 Nov 2024 10:47:38 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8F400AD9A8 for ; Tue, 19 Nov 2024 15:47:38 +0000 (UTC) X-FDA: 82803274134.29.B6E2D2C Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf04.hostedemail.com (Postfix) with ESMTP id D5E4E40012 for ; Tue, 19 Nov 2024 15:46:32 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wlDuchGn; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of jannh@google.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732031122; a=rsa-sha256; cv=none; b=4BRTIW/EkRPNfFsG127FIp7ZUptaquUDPOIrjpjX2PoSCW8DCX+YlVhCpNFm2O5DfMOJwf ko3FV9/d4YvpLY6ek5lM2R3M05uRV16/ZjHC5+phCV1lUVg+B9GBF3rulXUW9vdC3j4LYQ cizI9A1BI1mAu5XMZ9HAYs2Qr9glpTU= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wlDuchGn; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of jannh@google.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732031122; 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=i0rjD0JCBg2/0zk+DR3DU326HYcGm8Z8xgFiWJSGXFI=; b=jGDCimbc0QMxBgBpXg1tLXan96G4q4VRk4FIEIYAYxbAQS76wWnfFs8EEsbCcGnfL1bE1H uxJwuuKyvR14eufqzTne094sH8atIotGo5WcM3UnUQE3AUOUlkZfdpieWkJL/Ll5pAHbQx 0z16D6E/cWswdvh9ISGqs2BhK9PwDAs= Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-5cfc18d5259so8924a12.1 for ; Tue, 19 Nov 2024 07:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732031255; x=1732636055; 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=i0rjD0JCBg2/0zk+DR3DU326HYcGm8Z8xgFiWJSGXFI=; b=wlDuchGnMJzZH2BeN+fTJPjjm/oU8KRtjc0t4AWkY0EATXyMrvs89J0b/SmN6F1Uvy oZgRHZblAA7er2Z4QIOAxQM4ymNgWIym9oXPI+FtcX2l6cF/VUrD0LrlNnizQ5zfS5lM hELRmNzCduWylXEaS/D5w49ItHNAX81gNrcAVcbPxNN1RPhemDimzvQ7OBLvmupzX0n3 JwwCPRjKcpEclSWtQfc+AdbTOYtoOGDR5sA/YQXoozW81IJwcJjcCDI901JbuSxtWUxw diGgG4yTKGdyO+Amx1jL6WCyljn0xptjbDsIyIgntsH1XcbzvWN3ZJLPeupSITtdqXpG tOQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732031255; x=1732636055; 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=i0rjD0JCBg2/0zk+DR3DU326HYcGm8Z8xgFiWJSGXFI=; b=Dvt7m+hjq5ZWmEg8S87dA5gis66v8gGkOnJEoEzsN6oBGNOuJPlEMS0p8vVdJujpjr 0fuNmLJWbDZQc0/j1BMQHksEcCUBUbA1JGYGO19B9FYAB0ZxoZc8B1T1XV6lI8FOM0yo ETml5Blr2ppVu7O/KuPWeVCP/fGu8QguPMHr5tyclV0lF717Bh5vqK6bzxQp42mMdNM/ YDg5d6gJPewZKBbSFeblL5ZGA3BA6vXvpPyZktFfeSR8z8fMNsPLRuE3SQE3YkvB4VF9 FvtGUR1vtQyB8bndDprNHWoNsJu4Bu2hbJOGPADHYoknkfZWc54ro1mfUsaRKgDV1x7i RSYg== X-Forwarded-Encrypted: i=1; AJvYcCXWLaOz4cuxcFp+SRMd3BOaaNqSqLGqD3e7Cs1GQ6lLLwaANOY49S+wqE6bYCvz5UznoAc2uc38KA==@kvack.org X-Gm-Message-State: AOJu0YwzXfQVOsIdaDfYie9Lo8xW/vh3OYayuOZwVPSEpaoA40SUeC7D mzSes20R5ie/pE8vzH89XeSA0jmVQMLMbWKWet+37fL0SLuH9j6Ucz4isUzAVxSw4xlEpDvxuDo zSi7Ck/RgW6upEbCno2dzFf7Lkt2/2iXXg6nN X-Gm-Gg: ASbGnct+CXQvB5ST6hHNNwswtY1kXDXLCRfgPRKmeuNFU4oa3+HYtxWgvPo+8E2JSoF TX1JgvGaX9/8yfv6rnIdWuT5YuqLHOvXlJ+0A/nCkX7zI9JLRO29vo8b5gSw= X-Google-Smtp-Source: AGHT+IGkrk6XN0M17z4ufCr814Yn19SrMz2YIkhsZxhE4LIRO4vCs0Ui1plfIkV9z9o9Ahnh3t2phcBd7iF7Lrh5L30= X-Received: by 2002:aa7:c387:0:b0:5cf:c23c:2bee with SMTP id 4fb4d7f45d1cf-5cfdeb76bebmr83040a12.0.1732031254810; Tue, 19 Nov 2024 07:47:34 -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: Jann Horn Date: Tue, 19 Nov 2024 16:46:58 +0100 Message-ID: Subject: Re: [PATCH] mm: pgtable: make ptep_clear() non-atomic To: Qi Zheng Cc: pasha.tatashin@soleen.com, tongtiangen@huawei.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: D5E4E40012 X-Stat-Signature: 1jekzoj5n9j58uoxsn5z9w3akm9wgbek X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1732031192-976997 X-HE-Meta: U2FsdGVkX1/G22MzCrzXsgUoq4KU8UQpu8Dwilp+aiYo+iT1OKscv5y8kFk8n10wRllLrITi8EeCohL1Ee5JaOgorjI3CorDY71onlE0j9In07BY7pNCV0EHgDZp0F9Vqn4IMsE//1b/Z7AhHoBH18LHbrfKEjimQWwuAjFFr6JYIB1dzm21tb7FwmoL5lC3EsgP8eMGm4Hxer3xI1uTnMGbb5QXNqu0VezHZPM0yHlhLqH7d5KneTH6sqNgLukK9iw6/IkvEEo05uA0REpOez02SxiyyR2LPuXKlox5dBWKgwGRVuTemOsuQjSc4XKlgBYjw2slc1+8oKO0vV2ppJJAec9D4HUkU6cEZs06PWtPDWa/vYrwuErbXNQ4I+Y67JOMB5DisOPQ6f5tBfVoBvc9KYpJAytBxdXivh4cNusndTcAm/jrbZcQpGYSNevVKl5wWkvikoUURleQWK4HkyEMSQYJLKkXz6wzHW8wFJJnHltheN7A3OC7ayz+OBKzaEY3leuC/DH6eXMHh+rhp+YjOhlo+m77+BMqZnFHeTP4+R5wE8Jp7zPg+0s+mtu/oT9Dp6u2iMjmAeJFfbCzRPzY/I8mC8boMqw0CnNzpcEtcZWeJ4QuPfpyS+i6RIHYz1Z9m9yYPElYT/If3I5lp5ecgGNFY6i4/Xr6GNC8EScMIoFj4Q+MYy+GtotktAeyVoLTBuvgwY9nhPsj+0vaQQ9//brKZaEsxUIU92msnNW/Xf3tiWpGLkokqG9GTp8/5SbekBHqMqMUH6DytKdTUdXBbMQomSifV5Glzn944mMnFTIOGXoV+hUxsjg6p3Qd9y5a+PeIE26dzS3zqeseC3kQsoqultbkSMc+6OsxOOKwS0P3UeXkJK0ybcfoUpx6iVeNFxjsYpEhABsQJmo6phJmCiSFoEWl+ch6IINbzI7hF4tQS11RtDbhq7RYcPLdsVk7FEiz+CFtS5O406W T6MgcIGT gmYp73w69gZxTII2qswvO4/ci545gLEk+eYtcaECgMw5J/FpsaWtIHRbDIe7MROyJIR6O0zGAnqWMJHLxEZr2Xenv7C8lFHpDuWE8b/kmXIWRIq1iFJpO9JlAz91mRw4dvFWPC/L5uMwziJjtMq8K66OBhgI7KbNjJugtvJ1fnkAWzMsV2Ljx7oQrcWevLF9oDia9TiunU9c23XQqTBVs3AIlXVWoVXU6zyxEXWyYNSWNnxM+ykPxI1/nV14dmxc7RF+QFlp3+TiBgnCpZSozDzzf8NvNl4OXKexB 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 10: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 Yeah, as you mentioned on the other thread, this seems like a reasonable cleanup. Reviewed-by: Jann Horn