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 C5D99C433EF for ; Mon, 25 Jul 2022 17:18:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D13728E0002; Mon, 25 Jul 2022 13:18:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CC3A08E0001; Mon, 25 Jul 2022 13:18:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B63EF8E0002; Mon, 25 Jul 2022 13:18:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A677B8E0001 for ; Mon, 25 Jul 2022 13:18:43 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 80C8B80557 for ; Mon, 25 Jul 2022 17:18:43 +0000 (UTC) X-FDA: 79726281726.28.76C91E3 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf31.hostedemail.com (Postfix) with ESMTP id 2413D200A1 for ; Mon, 25 Jul 2022 17:18:41 +0000 (UTC) Received: by mail-pj1-f47.google.com with SMTP id o5-20020a17090a3d4500b001ef76490983so10892737pjf.2 for ; Mon, 25 Jul 2022 10:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dpM1aNkn3tjc2h94tGvxhUzJ41uNR44FywexRzBeVSg=; b=NFxhzonedhb8WWkKgoLqB5AT9pRaSVxaU6YWdbAgqEvPta8IhaNtC2R3J0LSKkcc7D 94DhOUWFbgyObaKYU+KuLmQVu5cqcJEq2YRlZDJ3xJnXQ2RGwOKbh0n51JgUbnLIvX5+ SBmh/jl9HBEqjCo5WV8nzA88bvqQkSPy6nOnOcCm5/bZ/UnPSHwh7a5e56J5n67sMJW1 zsS3f2enCKr41glU18uOwJT+mgt4YEH7goTWY+qvLDX243CYMnsYR5UMYzbCRebcvXsX LU1OfXqob/TS4LBSVl+6r3HvijFiZdbC1zZm3ci72nJMf776jsq2jwNyPUObLGNbXXC1 uZWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dpM1aNkn3tjc2h94tGvxhUzJ41uNR44FywexRzBeVSg=; b=b8FzqIpXy59UPHUMzOP7jmr7nl20iFhiZ16RoC4FYF07XOshac/vwYNy72951qmEX2 pc78UdFfm3ejUQua9CddFGMfyragEJe9pcigOf1mUsXB0QPS00aMJWuH5zcJahMn5xIq I5/KPwjUwXFCqurjfp2pcykxLyIxcVWlNa63wQeXAmTiKZFtWLrHsw0Qz0UHAV/1aQkl NNyLnABPJx0n8Z00Ew0Wnhf+XCnuwrcr8nzprMwfNVY7X1ic3UDgI0cpmXqkxq5jQ0LS sRdZFzLAbtVyIqkWkIGzbCIeK3ZzOIpcVcwqG3u8DA2W79qyuNigTU5dst3W7jw0m3yV 9DVA== X-Gm-Message-State: AJIora/VPnkV8naBC9XH18URFoLsS/9KF5UAZv3tYuugCnlHUk5zsEqa JTkvSqEX8nosA98b7xelMKg= X-Google-Smtp-Source: AGRyM1tzyvb1J3vxSdeS1I19h1Jz2JMXWvUln2mkpGXMnVAJbuVx63UwnHut1oBVTpuAOwERKZs+rQ== X-Received: by 2002:a17:903:245:b0:16b:9b6d:20bc with SMTP id j5-20020a170903024500b0016b9b6d20bcmr12659189plh.14.1658769520914; Mon, 25 Jul 2022 10:18:40 -0700 (PDT) Received: from smtpclient.apple ([66.170.99.113]) by smtp.gmail.com with ESMTPSA id 128-20020a621886000000b0052abc2438f1sm9864841pfy.55.2022.07.25.10.18.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jul 2022 10:18:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [PATCH v2 2/5] userfaultfd: introduce access-likely mode for common operations From: Nadav Amit In-Reply-To: Date: Mon, 25 Jul 2022 10:18:38 -0700 Cc: Linux MM , Andrew Morton , Mike Kravetz , Hugh Dickins , Axel Rasmussen , Peter Xu , David Hildenbrand Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220718114748.2623-1-namit@vmware.com> <20220718114748.2623-3-namit@vmware.com> To: Mike Rapoport X-Mailer: Apple Mail (2.3696.120.41.1.1) ARC-Authentication-Results: i=1; imf31.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NFxhzone; spf=pass (imf31.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658769522; 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=dpM1aNkn3tjc2h94tGvxhUzJ41uNR44FywexRzBeVSg=; b=wCe0SFczMEcGK4JpvuUIoYYCPIxrkoqEzmRB96dMol0tAFHj7Ebq4AQwPb4h6uhjjL4yAA F4woknNo8OhgAUfUZN6gVrOh4hi9XbR24LiSuTfKqRdWo4mhUTnUIk4CoQzTJi3npD7xJs drtG5N/v0pCn1QRRrPMUVqiNzrDtNmQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658769522; a=rsa-sha256; cv=none; b=6XBpDk6WAVZQ2Vxp+cL11Rumn0D5xCA+8hpMCTeV71t0WTvlna/FzPw2IKJ90RTcBqqJQ7 Knvg6ki/Ti5YTXF7TLaV0ggtbKKSD1z4I/Afdo0ZC9BOFgFvAwGfz8uyIwbm3oPTOoSSev AL+/YPvEluVrPWudNcdarjJUxDq6fJY= Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NFxhzone; spf=pass (imf31.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Stat-Signature: tubntj64uryxjfcehnbtamsk87s9r5g3 X-Rspamd-Queue-Id: 2413D200A1 X-Rspamd-Server: rspam02 X-HE-Tag: 1658769521-479170 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 Jul 23, 2022, at 2:16 AM, Mike Rapoport wrote: >=20 > On Mon, Jul 18, 2022 at 04:47:45AM -0700, Nadav Amit wrote: >> From: Nadav Amit >>=20 >> Introduce access-hints in userfaultfd. The expectation is that = userspace >> would set access-hints when a page-fault occurred on a page and would >> not provide the access-hint on prefaulted memory. The exact behavior = of >> the kernel in regard to the hints would not be part of userfaultfd = api. >>=20 >> At this time the use of the access-hint is only in setting access-bit >> similarly to the way it is done in do_set_pte(). In x86, currently = PTEs >> are always marked as young, including prefetched ones. But on arm64, >> PTEs would be marked as old (when access bit is supported). >>=20 >> If access hints are not enabled, the kernel would behave as if the >> access-hint was provided for backward compatibility. >>=20 >> Cc: Mike Kravetz >> Cc: Hugh Dickins >> Cc: Andrew Morton >> Cc: Axel Rasmussen >> Cc: Peter Xu >> Cc: David Hildenbrand >> Cc: Mike Rapoport >> Signed-off-by: Nadav Amit >> --- >> fs/userfaultfd.c | 39 = ++++++++++++++++++++++++++++---- >> include/linux/userfaultfd_k.h | 1 + >> include/uapi/linux/userfaultfd.h | 20 +++++++++++++++- >> mm/internal.h | 13 +++++++++++ >> mm/memory.c | 12 ---------- >> mm/userfaultfd.c | 11 +++++++-- >> 6 files changed, 77 insertions(+), 19 deletions(-) >>=20 >> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c >> index 2ae24327beec..8d8792b27c53 100644 >> --- a/fs/userfaultfd.c >> +++ b/fs/userfaultfd.c >> @@ -1708,13 +1708,21 @@ static int userfaultfd_copy(struct = userfaultfd_ctx *ctx, >> ret =3D -EINVAL; >> if (uffdio_copy.src + uffdio_copy.len <=3D uffdio_copy.src) >> goto out; >> - if (uffdio_copy.mode & = ~(UFFDIO_COPY_MODE_DONTWAKE|UFFDIO_COPY_MODE_WP)) >> + if (uffdio_copy.mode & = ~(UFFDIO_COPY_MODE_DONTWAKE|UFFDIO_COPY_MODE_WP| >> + UFFDIO_COPY_MODE_ACCESS_LIKELY)) >> goto out; >>=20 >> mode_wp =3D uffdio_copy.mode & UFFDIO_COPY_MODE_WP; >>=20 >> uffd_flags =3D mode_wp ? UFFD_FLAGS_WP : UFFD_FLAGS_NONE; >>=20 >> + if (ctx->features & UFFD_FEATURE_ACCESS_HINTS) { >> + if (uffdio_copy.mode & UFFDIO_COPY_MODE_ACCESS_LIKELY) >> + uffd_flags |=3D UFFD_FLAGS_ACCESS_LIKELY; >> + } else { >> + uffd_flags |=3D UFFD_FLAGS_ACCESS_LIKELY; >> + } >> + >=20 > This is quite a construct and it gets more complex in the following > patches. How about making it to a static inline function? Possible. There is another option though. I think it would have been much cleaner if some flags were in common offsets in the different =E2=80=9Cmode=E2=80=9D fields. It might be too late for some fields = (WP), but I can put these the ACCESS/WRITE fields in the the high bits in fixed place for all modes, which would allow to at least reuse the logic. Is that ok?