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 671B0C04A6A for ; Wed, 2 Aug 2023 15:28:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 049B52801B7; Wed, 2 Aug 2023 11:28:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3B022801AA; Wed, 2 Aug 2023 11:28:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2A622801B7; Wed, 2 Aug 2023 11:28:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D3D0F2801AA for ; Wed, 2 Aug 2023 11:28:53 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9DB49160F59 for ; Wed, 2 Aug 2023 15:28:53 +0000 (UTC) X-FDA: 81079547346.12.ADC544C Received: from outbound-smtp12.blacknight.com (outbound-smtp12.blacknight.com [46.22.139.17]) by imf10.hostedemail.com (Postfix) with ESMTP id B7A17C000C for ; Wed, 2 Aug 2023 15:28:51 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.17 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690990131; 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: in-reply-to:in-reply-to:references:references; bh=BFrX2TWcBsNAzS89yEbXMhB7TcCvpaFVUFRIexqnHg0=; b=O1jXmI+mYVey6RXprzcVpz2WON9H04WiaeNjuvV8nj2Mlp9cg3VMilm/c6wzWFgNvan4ke sZoOz/BRM528LSxAZRui9DvJzAgmvA6FBEDxaA0c5seNB4E1vufg6TO969DnRnbPIO729Y ZKU+k77A8/YJWueQOvPOgdpUjk8Scfg= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.17 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690990131; a=rsa-sha256; cv=none; b=ByaoPOXyLJ4dzcgfI4ZiwBJOCv81LUsVFa9qUuwgClNsOEklTmQxSpg58cLywHXfsvgTD+ 2nw5M59tOwCBCeKZTvqL0ZvSD2SlLVEeDMj8mG1W5YqXR9qaklblPOC8HZ9Shj3pWtflLg jrUelippy0hTDM4V541T/5wsOqOUBJc= Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp12.blacknight.com (Postfix) with ESMTPS id DEC381C43E8 for ; Wed, 2 Aug 2023 16:28:49 +0100 (IST) Received: (qmail 12428 invoked from network); 2 Aug 2023 15:28:49 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.20.191]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 2 Aug 2023 15:28:49 -0000 Date: Wed, 2 Aug 2023 16:28:47 +0100 From: Mel Gorman To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, Andrew Morton , Linus Torvalds , liubo , Peter Xu , Matthew Wilcox , Hugh Dickins , Jason Gunthorpe , John Hubbard , Mel Gorman , Shuah Khan , Paolo Bonzini Subject: Re: [PATCH v2 4/8] mm/gup: don't implicitly set FOLL_HONOR_NUMA_FAULT Message-ID: <20230802152847.c3pz5o4pfsmkuv3u@techsingularity.net> References: <20230801124844.278698-1-david@redhat.com> <20230801124844.278698-5-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20230801124844.278698-5-david@redhat.com> X-Rspamd-Queue-Id: B7A17C000C X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: b4o9p4u4qm96g7oo5m38xn4oezaz4xw8 X-HE-Tag: 1690990131-510792 X-HE-Meta: U2FsdGVkX18VLVALURTSox2Ngn75inN1jhLzpDx31r5ZLntd6cFY9wA0RgPh3HlVQhJoLZhyI1J0dN9wIn7l/sXCb1w22Azw/unFIKTUicfDDarqdVOFFve24Y7NlDKDe4Qg7721NT6Yd10xuQZvasVkiryev0JwdebwuYHnL72Cm6xOzpuX+4POVbJyqrUTV9Aj+yF8S4or3o9fSf7ur80SqpyHbjykBJVw8mgm22IxZUj85KGRQcIOYfAp4ct45jku0hp5EJx1ahfGfSuMODbiOT00AKYX2ulL7Sf50OpCd4YUydH/BStLJYenwMNoXkBsJyW3uq8uEPeTVDSGWSvmR4tFBK6vDRyfK6H8JudGXFh/kklb0Z1Cg4W9GMVXjCJlWbfDRiPeJX+1gXczCfxVbmzw5LbqBZ2LWgOLBgPqsKwUJvpiJKwkLe+V2oaq2E4x2W4+qFqbjVTazUftPd4+mDkCzxBiriGQ01WkBY+UGurbWwK5tF6TTIoB5fwjX7oHwFA6JetAIE6vTzRM+Cw1+3su43vdzUs2NeLwYuQy3tnS6JTwJ//CC555n3VgboBTs6PzLtP8qLBxP2XGGNNuvPDoqRBtEUa5f/0QyezXoyhf4hhkNI7UsXWrQY5fVzbbUJdNs51Quvtj290TeJ3tVWc0ZMHVHWzBC35FCnLXiXKT40qD3z5Xb+SpWRnk9txDusXjlNniU31pQrisLM9nMF+8FToKJZTOPmkNu8MSDIWUOWtuHG7eMNNCp3sB4svuid5CqPVBynmtujqfc7pjQydxBo4PRBwdWmLH0So7KUYlDJud6NUW9X5P2H/N8Mq3AYTr+GI0QOHHs5GUdW+kiq9+FcMX1omhoslGP+z8cs47S8VZ3nOimUvSNn++G9kQuk0jmZwQLgyY9BqA984HBlvf+yw8sGPvqIfek6SaL0fCDNBT23UH8Nn1nKdi3Jcos7sWwEgyIV3Ev60 nCoj/vRJ Ew+EwUzkCp/GhefFqwAHhO9d/5VPuGA3dbxYHbbVqVO1jquj1QXRWNOHcXmkWh8aaXsmm4dytvl4OCi12PSO+eT5OfZ/qnB/X500P7p0AbJiyWTkkK4gtRgyqHk0vPfBMz2JD4tlVXdn3xsIjKYZPogsQ4Of/tRbQspO19J3vjp7KBL25McgeKANbHKsWcHZ9l1T20f2WIl0bD7KSCYFuPcc86ZByqDkrZDEGDjBXDab+B7MNpSK3xNjNPrmjNYrP4+cBXOa9Q29Oj9Ziv2pckBQNp13wLRtgdXhfYJtJ4I+v9wKonD5ey50zTjyfxA1SpW58cJsMxCWOKew= 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: On Tue, Aug 01, 2023 at 02:48:40PM +0200, David Hildenbrand wrote: > Commit 0b9d705297b2 ("mm: numa: Support NUMA hinting page faults from > gup/gup_fast") from 2012 documented as the primary reason why we would want > to handle NUMA hinting faults from GUP: > > KVM secondary MMU page faults will trigger the NUMA hinting page > faults through gup_fast -> get_user_pages -> follow_page -> > handle_mm_fault. > > That is still the case today, and relevant KVM code has been converted to > manually set FOLL_HONOR_NUMA_FAULT. So let's stop setting > FOLL_HONOR_NUMA_FAULT for all GUP users and cross fingers that not that > many other ones that really require such handling for autonuma remain. > > Possible interaction with MMU notifiers: > > Assume a driver obtains a page using get_user_pages() to map it into > a secondary MMU, and uses the MMU notifier framework to get notified on > changes. > > Assume get_user_pages() succeeded on a PROT_NONE-mapped page (because > FOLL_HONOR_NUMA_FAULT is not set) in an accessible VMA and the page is > mapped into a secondary MMU. Once user space would turn that mapping > inaccessible using mprotect(PROT_NONE), the actual PTE in the page table > might not change. If the MMU notifier would be smart and optimize for that > case "why notify if the PTE didn't change", that could be problematic. > > At least change_pmd_range() with MMU_NOTIFY_PROTECTION_VMA for now does an > unconditional mmu_notifier_invalidate_range_start() -> > mmu_notifier_invalidate_range_end() and should be fine. > > Note that even if a PTE in an accessible VMA is pte_protnone(), the > underlying page might be accessed by a secondary MMU that does not set > FOLL_HONOR_NUMA_FAULT, and test_young() MMU notifiers would return "true". > > Signed-off-by: David Hildenbrand Also seems sane but a large portion of its correctness also depends on patch 3 being correct. -- Mel Gorman SUSE Labs