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 A6799C433EF for ; Thu, 23 Jun 2022 23:50:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29CEE8E01A4; Thu, 23 Jun 2022 19:50:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24E8A8E01A1; Thu, 23 Jun 2022 19:50:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0ECF28E01A4; Thu, 23 Jun 2022 19:50:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0282C8E01A1 for ; Thu, 23 Jun 2022 19:50:01 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id B1FEB120344 for ; Thu, 23 Jun 2022 23:50:00 +0000 (UTC) X-FDA: 79611146160.17.3025E69 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf21.hostedemail.com (Postfix) with ESMTP id 431A11C0009 for ; Thu, 23 Jun 2022 23:50:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656028199; 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=mLlMpOft1Y7JUK/5py+OhKk7oIddfmI13aUuALeCzZY=; b=FM04VaBRFs5c1C4WpQSYwfXcPIPTl3Sbp91NNsfPQhPPQcevOAnf2HMCtqnJ/ECTmHUoQ+ GLk0syU0zd6/JckI7uAycTTv/BeSKsbFzC0OwcxL4Dkrvam+XJ4QTPlXymrRB4a146T+Ax 7yvEvjfGr2nTidUBDJvolrwdI52u+vg= Received: from mail-io1-f72.google.com (mail-io1-f72.google.com [209.85.166.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-284-lu379oXjP7KnyYd0IaPkLA-1; Thu, 23 Jun 2022 19:49:56 -0400 X-MC-Unique: lu379oXjP7KnyYd0IaPkLA-1 Received: by mail-io1-f72.google.com with SMTP id q75-20020a6b8e4e000000b0067275f1e6c4so473404iod.14 for ; Thu, 23 Jun 2022 16:49:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=mLlMpOft1Y7JUK/5py+OhKk7oIddfmI13aUuALeCzZY=; b=mQb7kz7lNoF3GqmcpN/ViDqNGm3OyCOa3gXtmY6rCDi2+W2B1wpSjiMnMXriiUTqLj UPlVCOKLxTo4rcRE5gnymXmxNJGES5S/d/+67G5ST0xwB31xuh8PBEs2uzbm+FTkx4iD ksxDQusKj0bo/uLBqzdrwz1lHMZiI/YxDsD3X384DjWW1blWfprnYCnVjFC47NtAQ3K4 q03Smy6Es9HOh3CYXmRBm/PDThrigVm1CfdNdHYCvqF8k1nDv3UA1RxuNdSIs0kwdYAp ykbpsvTbWY9jp8WgR/oC+uQswVLvXywHTY01d2W3yGQkqjJArORzfYkEDUjgkJKSG9S0 PdfQ== X-Gm-Message-State: AJIora8U/SE50hHQLKOO3I63+H3tudlMWgDD4nh13CEfzUOvPslrSjBV 6JUvbMS05UPt6cem+NJKbvO5ifr4BoGZDrmXmQJlHS9GYCrngOouYxzOhe73w3q4gjnsEPy76RX V4gfNqKhYn6s= X-Received: by 2002:a92:c567:0:b0:2d1:c3df:eff8 with SMTP id b7-20020a92c567000000b002d1c3dfeff8mr6555893ilj.84.1656028195982; Thu, 23 Jun 2022 16:49:55 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t/TsSV5qcjBfLX+P6W6x+Vleb+xXTFvB4M8KaHmzCojm3TjrfCU2rDmLlwWuq/bkq++3EL+A== X-Received: by 2002:a92:c567:0:b0:2d1:c3df:eff8 with SMTP id b7-20020a92c567000000b002d1c3dfeff8mr6555883ilj.84.1656028195781; Thu, 23 Jun 2022 16:49:55 -0700 (PDT) Received: from xz-m1.local (cpec09435e3e0ee-cmc09435e3e0ec.cpe.net.cable.rogers.com. [99.241.198.116]) by smtp.gmail.com with ESMTPSA id q19-20020a0566380ed300b003316c1a2218sm361107jas.70.2022.06.23.16.49.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 16:49:55 -0700 (PDT) Date: Thu, 23 Jun 2022 19:49:53 -0400 From: Peter Xu To: Nadav Amit Cc: Linux MM , Mike Kravetz , Hugh Dickins , Andrew Morton , Axel Rasmussen , David Hildenbrand , Mike Rapoport Subject: Re: [PATCH v1 2/5] userfaultfd: introduce access-likely mode for common operations Message-ID: References: <20220622185038.71740-1-namit@vmware.com> <20220622185038.71740-3-namit@vmware.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656028200; a=rsa-sha256; cv=none; b=50t7VFWZGkukZMeXuJfeNnvQX4J0zJNEbe2W+FAs2tG7OBLCHd1jbmo8PNE1tn7I4tRYy7 cYDrNinacB3c5KeYA3xWNf+iqptNGEzlMoQi4J4Stld6thSAR1XSqZujskhk0tFHUfKZL6 c5iMClNIfPOPfsGDDffmxCbKn79ox38= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FM04VaBR; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf21.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656028200; 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=mLlMpOft1Y7JUK/5py+OhKk7oIddfmI13aUuALeCzZY=; b=hMiQm2laMgqkCBeBWYTL7z0NyjphVftPdBn0FbAp2Gb7NBvi23ap9wvn9OguJR2X6KC55h mNBFYI33W8kFlsr/ZjetM3cIDLf6mZId+ZX5t/P4Ns9JFSo+pNx5bfANPKXPdSaHBQDeV6 IJmH2plsMH0mDhP7HOobYdTR2COGlWI= X-Stat-Signature: 3r6qnyh9mjo6ub36xkpmd3t4ho541dh8 X-Rspamd-Queue-Id: 431A11C0009 Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FM04VaBR; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf21.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1656028200-681211 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 Thu, Jun 23, 2022 at 11:35:00PM +0000, Nadav Amit wrote: > On Jun 23, 2022, at 4:24 PM, Peter Xu wrote: > > > ⚠ External Email > > > > On Wed, Jun 22, 2022 at 11:50:35AM -0700, Nadav Amit wrote: > >> From: Nadav Amit > >> > >> Using a PTE on x86 with cleared access-bit (aka young-bit) > >> takes ~600 cycles more than when the access bit is set. At the same > >> time, setting the access-bit for memory that is not used (e.g., > >> prefetched) can introduce greater overheads, as the prefetched memory is > >> reclaimed later than it should be. > >> > >> Userfaultfd currently does not set the access-bit (excluding the > >> huge-pages case). Arguably, it is best to let the user control whether > >> the access bit should be set or not. The expected use is to request > >> userfaultfd to set the access-bit when the copy/wp operation is done to > >> resolve a page-fault, and not to set the access-bit when the memory is > >> prefetched. > >> > >> Introduce UFFDIO_[op]_ACCESS_LIKELY to enable userspace to request the > >> young bit to be set. > >> > >> 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 > > > > Hmm.. is the hugetlb code overlooked (for both of the hints), or maybe I > > missed it? Do we need to cover them too? Thanks, > > I do not know what the value of not setting the PTE’s access/dirty when it > comes to performance. The pages won’t be swapped out, just as you wrote in > your comment in hugetlb_mcopy_atomic_pte(): > > /* > * Always mark UFFDIO_COPY page dirty; note that this may not be > * extremely important for hugetlbfs for now since swapping is not > * supported, but we should still be clear in that this page cannot be > * thrown away at will, even if write bit not set. > */ > _dst_pte = huge_pte_mkdirty(_dst_pte); > _dst_pte = pte_mkyoung(_dst_pte); > > If you want for consistency/robustness not to set dirty on read-only > entries, that’s something that I can do. We have more than one options here I guess. We could have the hints not available for hugetlbfs, but then we'll both need to add special document for hugetlbfs (when you write the man-page, let's say) and also it'll be probably better to fail the ioctls with hints when applying to hugetlb vmas. Leaving them silent to hugetlbfs is another option, it just sounds weird to me without any kind of documentation so I like this one least. Or we could make them work for hugetlbfs too. Not saying that swap will work some day (but it still could?!) it just seems all consistent as you said. So I'd prefer the last one, but only if you agree. -- Peter Xu