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 97AA0CD11C2 for ; Sun, 7 Apr 2024 07:37:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 146446B008A; Sun, 7 Apr 2024 03:37:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F6346B008C; Sun, 7 Apr 2024 03:37:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F00266B0092; Sun, 7 Apr 2024 03:37:18 -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 D27506B008A for ; Sun, 7 Apr 2024 03:37:18 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5EB701C0984 for ; Sun, 7 Apr 2024 07:37:18 +0000 (UTC) X-FDA: 81981930156.10.AF35D4F Received: from out-178.mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) by imf19.hostedemail.com (Postfix) with ESMTP id 726661A0004 for ; Sun, 7 Apr 2024 07:37:16 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=dNt3tV3X; spf=pass (imf19.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.178 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712475436; a=rsa-sha256; cv=none; b=RxwppHj3AH5VeQBbyehQF2UKPOnGocs8N1hDK3WGjOhHXMlkjRDffBTJund3XgZsx5BfVu eaikPktCM/DLcm0wQ+NEugDOI/5fCMZQgMixQ0v1FOBiavrbNoLYguZdhO0tEP4uwG06FM Pj3g1L+qu0PSgBGvbjIfHpRr4zKhoNA= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=dNt3tV3X; spf=pass (imf19.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.178 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712475436; 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=0Bahn4KQkeBpv/q05dP0qudxz14FvAOhzQLd0ktghZo=; b=v8Lj/NrX7fhIgV3n7U1ZGNVTXykD5s4hM4sLzzcozzGEL/rQel5LItWOQyAICLXJUSvM3S evWZ2qh7gfxFg27h+Wt/bnZgFexg0F5U3ErjW9PFmPrIelf0gZ+HWbqdSb/EvhUBHbRRuk y9eMRLNGCBvSfIPal1AsfyVqfhaGw7w= Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1712475434; 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=0Bahn4KQkeBpv/q05dP0qudxz14FvAOhzQLd0ktghZo=; b=dNt3tV3X/x1eFdBkdX9rtEbIxNSBBvklJ9jTVTQMJBQbW0XgXfH2oqZlTeJOMjcan7QjRi yM+MxrtNmgsKHnvPgTlCs6QpZ4aJ6HEvOOkUOQtMkYlJkfw60fwDjulqvo/rrBoi18nYDC zwGnXXkMgQGBWyJtt7dBxR51t8rMHiE= Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: [PATCH v2 1/3] hugetlb: Convert hugetlb_fault() to use struct vm_fault X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Sun, 7 Apr 2024 15:36:39 +0800 Cc: Oscar Salvador , Linux-MM , LKML , Andrew Morton , "Matthew Wilcox (Oracle)" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20240401202651.31440-1-vishal.moola@gmail.com> <20240401202651.31440-2-vishal.moola@gmail.com> To: Vishal Moola X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 726661A0004 X-Stat-Signature: z5p1k9dxuenoszud15xdtqgiredm5er3 X-Rspam-User: X-HE-Tag: 1712475436-304600 X-HE-Meta: U2FsdGVkX1/hW7nGLICgUhKI2w0QyZErQgqw1P8mKBT6TKGQlR4pbQDXiJoFmc3gynA7DDHD7BlEfxdc+dL40wyaCVibhh6pJscYi310CVADciqnbMJdu4D4MonkwEArLUsBUYytyZa9wMOpxH9ZlHZHiiDXk1jTiscKxpL+m+pooiaDgQ8I2Ah9VbAjKDb6AKGdrMJ/oozrh8G1D1phU4FYrP0VZgrGB/5QZijeyQpV0e0QybPTYLSfZJNS1Ycnz6FLLWTne+dFc2csMLuOvvDMFDZfzaiCEDbv7ptf0ADjloJ790HGa88WUJh6nGoTOg9CjRq4YUrxNgr+BTWeShcfovhspYK3WBRfko5jQiM7AGGX3n/bPupjvTY6vv4kPmBNOh2tAGKgk9yNYIgjX3Tg5f/uOuL5kPP3Ru1eDk0h8koK9hQ5MxD9HzZVeKG81A9TjGiyJaF84IyO6fz+cxvptPLRkTPHr2x10UV1ZbPMs+dhsWbNl03mt9OlTnBmdy2xfToLsQYvycLTog2w4cdgJI7NQzBEfa7LV0ZUiT+y51Rp0ZzAdEtxDpuBM+jIO3zVwg+Yz/K7lddgEXwMApFUpfa1hjChx5tEQz54+vCwjiqCuifaXglHXpSy286M50t9d6m6+nnO1yjM9ynReuBb9ar73cu6J5LctpxOJmkkJnEWlHfYoXbjGfRxjBY28uX1F7nJEQcc2JYfT4V1A7RmwdKl7YMfP+OrtNEdwpo4Kosu9nnjwDk51rR3ce7ESbSPoUeGQ6DsveSjeLm+6LxQaeYn5vEkSqnL0WDp0+3GSrDvtnIESZ2dzl67sHztYDr0h+8LjLnI1AcVJvw3vruQePBlXCPKT02NpcpclxiPPg/hTRD82g9y/rJZdzcx+dx61aRfi+0oS2gU/CM+vpArh9ihR5cmiBo3FJCzzH0fwznv6mnIzXVAms8abyPa6NE+VN5B9r1Os5xR2S8 u4fAIvBh JaiGs7IiXp4J1GZroeDRR8bGAiqqck62zbrOCyQR4cmE6zUu45yyBLD4XvIJfLFP2WzctkHWszR9x5yrlAHZj5xqqpWhMp0BrdHTpT4+HLLqbHegrWXHuGv3ZrsdaK0Fu5fkZATgwfHvDy0b/2/MFEMGyV+4t9SXPfUuWAKbt+lic08O2ZE/me8VquSVF/s7rm3KKk45qRigzUGry4zg+2bw8Brb30eFruo2JsVN18E8aZYu0Wgrw64na8uJeNVf31bLkR2GCEj2CMRxerpSLArcsRyV/jBa/eR76 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 Apr 5, 2024, at 03:32, Vishal Moola wrote: >=20 > On Thu, Apr 4, 2024 at 5:26=E2=80=AFAM Oscar Salvador = wrote: >>=20 >> On Mon, Apr 01, 2024 at 01:26:49PM -0700, Vishal Moola (Oracle) = wrote: >>> Now that hugetlb_fault() has a vm_fault available for fault = tracking, use >>> it throughout. This cleans up the code by removing 2 variables, and >>> prepares hugetlb_fault() to take in a struct vm_fault argument. >>>=20 >>> Signed-off-by: Vishal Moola (Oracle) >>=20 >> Reviewed-by: Oscar Salvador >>=20 >> A question below: >>=20 >>> mm/hugetlb.c | 84 = +++++++++++++++++++++++++--------------------------- >>> 1 file changed, 41 insertions(+), 43 deletions(-) >>>=20 >>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c >>> index 8267e221ca5d..360b82374a89 100644 >>> --- a/mm/hugetlb.c >>> +++ b/mm/hugetlb.c >> ... >>> /* >>> - * entry could be a migration/hwpoison entry at this point, so = this >>> - * check prevents the kernel from going below assuming that we = have >>> - * an active hugepage in pagecache. This goto expects the 2nd = page >>> - * fault, and is_hugetlb_entry_(migration|hwpoisoned) check = will >>> - * properly handle it. >>> + * vmf.orig_pte could be a migration/hwpoison vmf.orig_pte at = this >>=20 >> "vmf.orig_pte could be a migration/hwpoison entry at ..." >>=20 >>> - entry =3D pte_mkyoung(entry); >>> - if (huge_ptep_set_access_flags(vma, haddr, ptep, entry, >>> + vmf.orig_pte =3D pte_mkyoung(vmf.orig_pte); >>> + if (huge_ptep_set_access_flags(vma, vmf.address, vmf.pte, = vmf.orig_pte, >>> flags & = FAULT_FLAG_WRITE)) >>=20 >> Would it make sense to teach = huge_ptep_set_access_flags/set_huge_pte_at() to use >> vm_fault struct as well? All info we are passing is stored there. >> Maybe it is not worth the trouble though, just asking. >=20 > Yeah, it makes sense. There are actually many function calls in the > hugetlb_fault() and > __handle_mm_fault() pathways that could make use of vm_fault to clean > up the stack. >=20 > It's not particularly complicated either, aside from reorganizing some > variables for every > implementation of each function. I'm not really sure if it's worth > dedicated effort > and churn though (at least I'm not focused on that for now). Not all the users of set_huge_pte_at() have a vmf structure. So I do not think it is a good idea to change it. And huge_ptep_set_access_flags() = is a variant of ptep_set_access_flags(), it's better to keep consistent. Otherwise, I think both of them should be adapted if you want cleanup. My tendency is to remain unchanged. Muchun, Thanks.