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 D806DC43334 for ; Fri, 24 Jun 2022 02:05:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B2FD8E01B7; Thu, 23 Jun 2022 22:05:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5629B8E01A1; Thu, 23 Jun 2022 22:05:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 403488E01B7; Thu, 23 Jun 2022 22:05:12 -0400 (EDT) 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 2C2AC8E01A1 for ; Thu, 23 Jun 2022 22:05:12 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 022E5120283 for ; Fri, 24 Jun 2022 02:05:11 +0000 (UTC) X-FDA: 79611486864.04.D47C154 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 5D835120024 for ; Fri, 24 Jun 2022 02:05:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656036310; 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=OAbQXFgcHNAbzecRqI1CBDtspUnQnMEuxeNBmA7TsV8=; b=CTsr8vXLK+uCDvCjagoSi0rmGaFPSpqtovfkwte/9ckbw/+dXojz+EGTD5HLjJ9IdYXUjN 1ERt0+W2s4Le8T4VLMszv4NhLIcmgW/Gd7fbNJ6bPY6dx0i2bWwEor8+ml1HPGV/OooEEm 9MnVyy6KaN8rgR4KIFjI5P2rMEQb+Jg= Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-455-4SDeBV2rMMi2nU_DG6vNwg-1; Thu, 23 Jun 2022 22:05:09 -0400 X-MC-Unique: 4SDeBV2rMMi2nU_DG6vNwg-1 Received: by mail-il1-f200.google.com with SMTP id 3-20020a056e0220c300b002d3d7ebdfdeso496384ilq.16 for ; Thu, 23 Jun 2022 19:05:09 -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=OAbQXFgcHNAbzecRqI1CBDtspUnQnMEuxeNBmA7TsV8=; b=qCUR899M0egjKywmvPfgVGtn5sy+Omgq0OWOIG/BoU06o2SsGYbZb0+/C4B46zc+ji iKCpwQzULEOY6RQNrCbV+SLyBdJrFnA9Lx6lhOAnYVhO2FEsa3IVeGMjTs5CgwEcOrUR 1KxEPzFQgLw+DnTaaDQOmqmtQpxy+UW5H+Thx7gbExZ/ZxFGT2761UQI0y7Bs3RYvYlf d9yWGFi0t1awqE24WEtUjuZDE6g3fd139aloet0Pvbg0QP3AF7JVvGbErcEYg+tCRVTa Lo4N+eDUT3kDr5cDV9cjjv6kgB6KSsGl46MNBhtsOnJ5fM+/W9sHeNbb0uX22T99fHe5 Vmqw== X-Gm-Message-State: AJIora8db6QVj/cNYOm+vkY90dhWfggb2N4qbdzRGxNFNyTEAIUBcMLK k++lCUDBDnWwQM33E6tTifiyqBSEYWsj9gqxIaNGzphto0UIYfbnZiJhvxR1nG8gw4DQL2rgt8s gnyxoVMg1pmk= X-Received: by 2002:a5d:9245:0:b0:672:77b7:cd87 with SMTP id e5-20020a5d9245000000b0067277b7cd87mr4732112iol.64.1656036308621; Thu, 23 Jun 2022 19:05:08 -0700 (PDT) X-Google-Smtp-Source: AGRyM1s92T1UOzRO3ZA5EwWhUB3zUYU1hQ5g6acFIK9/Up4EFKCZ/6o/00jT5JS4zViTr1cfHcfooQ== X-Received: by 2002:a5d:9245:0:b0:672:77b7:cd87 with SMTP id e5-20020a5d9245000000b0067277b7cd87mr4732101iol.64.1656036308373; Thu, 23 Jun 2022 19:05:08 -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 q4-20020a056e020c2400b002d95c4d56d3sm541017ilg.76.2022.06.23.19.05.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 19:05:07 -0700 (PDT) Date: Thu, 23 Jun 2022 22:05:06 -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> <18BCC23E-B344-41A8-926D-A49D768485AF@vmware.com> MIME-Version: 1.0 In-Reply-To: <18BCC23E-B344-41A8-926D-A49D768485AF@vmware.com> 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=1656036311; a=rsa-sha256; cv=none; b=xU4x+WRLTXoCtXzWZqXGQD9ICxT6Jus+LEYTcW0eFkwcoeKbFnH1hL7/Vy0E672M8r548d sgd3SFSKv//inT1TlYiyQ03FHOYFgiaL+CNVlQVTFzYdSLG+ypgsn+++BpqmcnDkdjVfHu IksuOEXKamzzRUwLzoKp2s555VX13L4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656036311; 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=OAbQXFgcHNAbzecRqI1CBDtspUnQnMEuxeNBmA7TsV8=; b=REHoiDXfVjVAronvDP1KlMV4YF1bjONlXWC6l8dyRiseqHWCNYxg2j8bGyhu1bMe+Fsvk2 g0y6JolAzn28mOnOsrXa2Xki7JzgG4it8lhwqWl3KRBLlzCjdVyQyiqBrHVc/3mTIX1ocW /9OKtvboSLSYoaXoyCN47qDb/oPMQPM= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CTsr8vXL; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf29.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=peterx@redhat.com X-Stat-Signature: m3a1fif7iynyw95xaty1nqzzpghzpy3w X-Rspamd-Queue-Id: 5D835120024 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CTsr8vXL; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf29.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=peterx@redhat.com X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1656036311-491919 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 Fri, Jun 24, 2022 at 12:03:38AM +0000, Nadav Amit wrote: > My take is that hints are hints. Following David’s (or was it yours?) > feedback, I fixed the description to indicate that this is merely a hint and > removed all references to dirty/access bits. The kernel therefore can ignore > the hint when it wants to or use it in any other way. I fully agree that > this gives the kernel the ability to change the behavior as needed. > > Note that for write-protected 4KB zero-page (where we share the zero-page) > we always set the access-bit, regardless of the hint, because it makes > sense: the zero-page is not swappable and therefore the access-bit is set. The zero-page example makes sense, and yeah that makes the hugetlb behavior making more sense too. > > I think that the lesser user-facing documentation there is on how the > feature is *exactly* used by the kernel - is better from an API point of > view. > > So I see no reason to fail or be forced not to set a page as young, just > because a hint was *not* provided. This would even be a regression in the > behavior. The hint is actually always respected right now, it is just that > even if you do not provide the hint, the access/dirty is set. > > The only consistency I think worth thinking about is with the dirty-bit, and > I can add it if you want. Note that the access-bit (in x86) might be set > speculatively in contrast to the dirty-bit is only set atomically with a > real access. That’s the reason I think it may make sense not to set the > dirty without a hint. Sorry to ask if this is (another) naive question: any link/help to explain the speculative behavior on access bit? Is it part of speculative execution (which, iiuc, would it be reverted if the speculation failed)? > > Is that acceptable? Access-bit always set, dirty-bit according to hint? I'm still trying to digest what you said above, sorry. Aren't both access and dirty bits need an atomic op to be set anyway? Then from perf pov should we simply keep setting them both too like what you did with this version? because it seems that'll always avoid an extra pgtable update access? -- Peter Xu