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 9A329C282D1 for ; Thu, 6 Mar 2025 14:33:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 83CC3280002; Thu, 6 Mar 2025 09:33:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C6E1280001; Thu, 6 Mar 2025 09:33:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66764280002; Thu, 6 Mar 2025 09:33:54 -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 44895280001 for ; Thu, 6 Mar 2025 09:33:54 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4849581F0D for ; Thu, 6 Mar 2025 14:32:27 +0000 (UTC) X-FDA: 83191366776.13.01EE2F7 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf21.hostedemail.com (Postfix) with ESMTP id 99F751C0019 for ; Thu, 6 Mar 2025 14:32:20 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf21.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741271541; 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; bh=XuoazaomkiNROZ6XzYB5t1h2irlz/rvCBC3zc9Vgg98=; b=kiMcW5wbtTmc68BVPXvgJv+6Qle20D84YWF5BJH4ig2ZG2mqVjvKnFyKV/nrM6IIih3PeF puGPaTCL8JZ2bnY4l5Pw0C1LUUIXmjcTV7UxpPb/lJCDjrShCYgrFVKJ9chpw+WmSJArGH 7bbPNORpZeh3sfLi4Ja+YLXneZSGGY0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741271541; a=rsa-sha256; cv=none; b=5z5irFjrLD9hfAWpSI7lAE2Tt8A8haG+f//xObUF73nVypFY8WTCvJnYtquXTo3aJQYEqA qi45B/R/8wgQuWWat6AD2U55peaNZs9RQvlTdVDmmuLwvKqYtyobOsNot2gZ1vqywygHXE KgTCPpBma4fdZQwuq84Sz8AKBGgMVV8= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf21.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 046631007; Thu, 6 Mar 2025 06:32:32 -0800 (PST) Received: from [10.174.36.159] (unknown [10.174.36.159]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2F61F3F66E; Thu, 6 Mar 2025 06:32:13 -0800 (PST) Message-ID: Date: Thu, 6 Mar 2025 20:02:10 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/vma: Do not register private-anon mappings with khugepaged during mmap To: Lorenzo Stoakes Cc: akpm@linux-foundation.org, Liam.Howlett@oracle.com, vbabka@suse.cz, jannh@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ryan.roberts@arm.com, anshuman.khandual@arm.com, aneesh.kumar@kernel.org, yang@os.amperecomputing.com, david@redhat.com, willy@infradead.org, hughd@google.com, ziy@nvidia.com References: <20250306063037.16299-1-dev.jain@arm.com> <67f0916e-9825-4105-b044-a16c0e82e736@lucifer.local> Content-Language: en-US From: Dev Jain In-Reply-To: <67f0916e-9825-4105-b044-a16c0e82e736@lucifer.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: 5okw7wr1we9nriuuetoo73nyccbd1wap X-Rspamd-Queue-Id: 99F751C0019 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1741271540-557517 X-HE-Meta: U2FsdGVkX18TVJPND/UIE1iZMMUVTB8gh81xrlsCXnC/jXg1w36h69VKq2LXhyTVfdM1vigHQZ5r7+bzlemFjtA4XKytm8v/zWBrxMAaIaTk1ynmAUMpYxCEWY7ph3y8MBwQ0GogLEN07vL8WGXQnfs+AhhUfFm6SuCSiJ5kzVXxCUwUbnzrmrOYkg4f24vTG7o5vxsZSKZutLDxuo2/hP/M9XjADzSiAKNk+XQYgQ2nUZGOWcgwjXTEvGR6BvTQPX2Cj4FNBYrOD3ixsd9VnnmXvra31N+2+clVW+l1UulSXIBYfwo8OwHL53iew1QGhy1DT6CYYY9+pVtWJ5594r4iRlr3Sv2aG2u5Gl0LVn29G/S1L6fevDYra3HKoWosSmu6g5WqLmwTu0EQBzUxs5yEy3MWsZVEuYCHOQC1r/2rDWSJFJzHoaATkR3TQiTde6H9hAqnePg/J/oh2k2ig7ahabVycAYQyuD8b+HYK4ZlpkdPWRF16yxdbqPsShVGBBj5Ggku0zfe+kW3YkVPrSBvf6tT+bCr7OZv6Eu29u42bsU8/ZpcmUQK7Ic+McC6SA+cjGAe1XN6Fgh6g0NVUqwyYDOoUg/RgWHbLQ1qu5Dkr3aLDMsrFknatPG8uzcYXG7RngcIAlm16Km2CtrgltkRFQhTPodfpiKpM9p1fcOCrncetofHPcQZxr1uPwBq+r8ruob97lySClymHtO+qZABqHm82WzMykPe5+SXB8wmcXKpf95nfC3bBU5PRLEw3brryhmkPhzU12vz/K5fSzT2sde3zX8Ku43uaMBV8L7znjoIxK4LuPLeatmuZAbG3t0ddSgX9EO8Me8kDBJUQ03W4bZ7BTPimatzc1yazMqogXiOcSfMpDXi0wdRp1EOfAK+gk6Di3w5tYyI1re1LU/O5/NZSAsGBJyj3gZO4b7ZU4JPUflkCkEuNqRR72uoZZv/AJcrQo1P8f4P64C px1LpLgT J2obeQSKu0v1UBk0Jzas21QYAPPqJSb/khqd8u/e0DPJWcg/AkR/78RiAY+Zj4TIbANJf/nQPNasV+O9vCY0Hvoz7JPQbMunWH96yMgmpMJ/9KbTlO/ypk5lgYd0OKYWvE40a6DSrgzA8jBH35qRtEF+J2vcmq6oXQJtLNV28Rih9g2NMv9YtZqiB+WboLg3pLB9c8zkTOVDip4s= 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 06/03/25 1:48 pm, Lorenzo Stoakes wrote: > On Thu, Mar 06, 2025 at 12:00:37PM +0530, Dev Jain wrote: >> We already are registering private-anon VMAs with khugepaged during fault >> time, in do_huge_pmd_anonymous_page(). Commit "register suitable readonly >> file vmas for khugepaged" moved the khugepaged registration logic from >> shmem_mmap to the generic mmap path. Make this logic specific for non-anon >> mappings. > > This does sound reasonable, thanks! Though does need to be expanded as > Andrew says for user-visible effects just to be crystal clear. Sure. > >> >> Fixes: 613bec092fe7 ("mm: mmap: register suitable readonly file vmas for khugepaged") >> Signed-off-by: Dev Jain >> --- >> mm/vma.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/mm/vma.c b/mm/vma.c >> index af1d549b179c..730a26bf14a5 100644 >> --- a/mm/vma.c >> +++ b/mm/vma.c >> @@ -2377,7 +2377,8 @@ static int __mmap_new_vma(struct mmap_state *map, struct vm_area_struct **vmap) >> * vma_merge_new_range() calls khugepaged_enter_vma() too, the below >> * call covers the non-merge case. >> */ >> - khugepaged_enter_vma(vma, map->flags); >> + if (!vma_is_anonymous(vma)) >> + khugepaged_enter_vma(vma, map->flags); > > This really needs a comment :) as a Joe Bloggs coder coming to this my > immediate thought would be 'huh? Why?' > > Something like: > > /* Just added so khugepaged has nothing to do. We call again on fault. */ > > Would be great. > > Thanks! Sure. BTW does this patch merit a CC:stable? I am not aware of the general practice but I am not sure if this is a *serious bug*, as per submitting-patches.rst. > > >> ksm_add_vma(vma); >> *vmap = vma; >> return 0; >> -- >> 2.30.2 >>