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 9EE50C433EF for ; Tue, 28 Jun 2022 20:56:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0632A8E0002; Tue, 28 Jun 2022 16:56:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0132E8E0001; Tue, 28 Jun 2022 16:56:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF56E8E0002; Tue, 28 Jun 2022 16:56:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CC7E28E0001 for ; Tue, 28 Jun 2022 16:56:45 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A400037F8B for ; Tue, 28 Jun 2022 20:56:45 +0000 (UTC) X-FDA: 79628853570.08.FDF49AD Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf23.hostedemail.com (Postfix) with ESMTP id 7398A140036 for ; Tue, 28 Jun 2022 20:56:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656449803; 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=HZbTbV2SJJxAZmnccLDdDi+LpWAYXzOJr2O8HIKI5N0=; b=G3H9EkhyQGfHGkgrC1Gi7ldOuHT5AtnV3wLR6DhB5ub2m/I7Tf20CftwbBO3b1Ih0cxEHl 7D2/WEiXw+AK16cENfxk//OdmI3zyXglybHxZtrztyClzi/yvjK5F4wJi6vLWOG2TN7K3Y HmmgM8/fm5r4odHvv+xb8RXfcpwKtuo= 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-564-kIE6fUXcMhmanSjNIqBZRw-1; Tue, 28 Jun 2022 16:56:42 -0400 X-MC-Unique: kIE6fUXcMhmanSjNIqBZRw-1 Received: by mail-il1-f200.google.com with SMTP id z1-20020a92cec1000000b002da6e27e130so6718690ilq.2 for ; Tue, 28 Jun 2022 13:56:42 -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=HZbTbV2SJJxAZmnccLDdDi+LpWAYXzOJr2O8HIKI5N0=; b=tgc9myzsDSIUJIMy1kuPzvouOy504jbaTzhRroQxiiSgGRgXL0R70I8M414/99D7BF vcOhrCv+lUho98WmUFr/CKvwCV14MDUsN2QqT8E6d/Un2Ul+iWBdqOM1wxdqu1C/Cf/7 Q6z6n8gf2AFbRJ0XvFh+iUPACs3V8AS+XkGtQelFZtcGjY/RaaTR+sIbbVTzKcmVEUto 1yiaMrBMSV5iajzMGKZ6aEteJ5EeTBLU/HRVWghYynBGYOE6S9LzEbHEvaAX13GTyk15 062z/gM31rbCDwNw2bCzkIB295xapWJ4TXPTrbCJlajufTt6TcNnGztvyDy0lBWePWDc cv4A== X-Gm-Message-State: AJIora+wiYZhVtK8sBx14CYlSBXBs72L3xQwAC0MWjokz5GHV0xMK1Ua SxMjqgxAsCfUYp5CC2+w7cNc6baCb1My/Xmod8MeofqKg4o8lHdnghv8fA1MR3dBnyaIFgngQW7 +e8za+sdP3Q0= X-Received: by 2002:a5d:93d3:0:b0:649:4310:602f with SMTP id j19-20020a5d93d3000000b006494310602fmr10289077ioo.13.1656449801567; Tue, 28 Jun 2022 13:56:41 -0700 (PDT) X-Google-Smtp-Source: AGRyM1skRVDJLcKARLrvlibFYlWn3FQmkhIOr2wY+DcZHR1mSoZNgeDH0I9mECRqLvWkJAL+Hm6JLQ== X-Received: by 2002:a5d:93d3:0:b0:649:4310:602f with SMTP id j19-20020a5d93d3000000b006494310602fmr10289055ioo.13.1656449801287; Tue, 28 Jun 2022 13:56:41 -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 y3-20020a056638038300b00339cb765806sm6330721jap.142.2022.06.28.13.56.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jun 2022 13:56:40 -0700 (PDT) Date: Tue, 28 Jun 2022 16:56:15 -0400 From: Peter Xu To: Nadav Amit Cc: Linux MM , Mike Kravetz , Hugh Dickins , Andrew Morton , Axel Rasmussen , David Hildenbrand , Mike Rapoport , Dave Hansen Subject: Re: [PATCH v1 2/5] userfaultfd: introduce access-likely mode for common operations Message-ID: References: <18BCC23E-B344-41A8-926D-A49D768485AF@vmware.com> <6EF7D3B4-CF17-407B-A50F-B14D595E99A5@vmware.com> <07B65135-CA6D-4839-BAC0-6D63A94F50C2@vmware.com> <9B0B584B-DE1B-48E3-B448-9D6C02DBDD20@vmware.com> MIME-Version: 1.0 In-Reply-To: <9B0B584B-DE1B-48E3-B448-9D6C02DBDD20@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-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=G3H9Ekhy; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf23.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656449804; a=rsa-sha256; cv=none; b=IWs8ktuGzTJY3DUQ6Vg91DDVtwP9Ky8ASw7P82n2ndi7JfN2TzBRgAhE2f2/HzBybraNeS GShMiZkuUAsBOS6Gn2MDZ7hs0IpWAZQ6TZYjLsTNrUfZu93Vjt/Ay7TaABVmAt7nJNt6Np oEHOpqKLSSdydsVgtdRRbs4npLVGLmM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656449804; 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=HZbTbV2SJJxAZmnccLDdDi+LpWAYXzOJr2O8HIKI5N0=; b=ZW8o7QEjjKMeY54BmJIo0CoJgxb6JEdPL0UNVRcLiLDMSdq3hxJXzhE1qv34DYx7Kjvor5 U/yiay3EAwbIOulQ9aDa1PEzWXW5qp7D5ydLQHqA6lYN7QT12u/SuoDBCXA0bRnjPKBbRj caO+d+HzVDxEBzP57cyKR3BbImNpGXI= X-Stat-Signature: 33ezkihhcbyzobqfzzxbaqfp9ti6yux1 X-Rspamd-Server: rspam08 X-Rspam-User: X-Rspamd-Queue-Id: 7398A140036 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=G3H9Ekhy; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf23.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com X-HE-Tag: 1656449804-523205 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 Tue, Jun 28, 2022 at 08:30:46PM +0000, Nadav Amit wrote: > > > > On Jun 28, 2022, at 12:15 PM, Peter Xu wrote: > > > > ⚠ External Email > > > > On Mon, Jun 27, 2022 at 11:37:32PM +0000, Nadav Amit wrote: > >> > >> Besides the benefit of avoiding a TLB flush, there is also the benefit > >> of having more precise dirty tracking. You assume UFFDIO_CONTINUE will be > >> preceded by memory write to the shared memory, but that does not have to > >> be the case. Similarly, if in the future userfaultfd would also support > >> memory-backed private mappings, that does not have to be the case either. > > > > Could I ask what's the not supported private mapping you're talking about > > (and I think you meant "file-backed")? I thought all kinds of private > > mappings are supported on all modes already? > > Yes, I meant file-backed. See vma_can_userfault() for the supported > types of memory: > > static inline bool vma_can_userfault(struct vm_area_struct *vma, > unsigned long vm_flags) > { > if (vm_flags & VM_UFFD_MINOR) > return is_vm_hugetlb_page(vma) || vma_is_shmem(vma); > > #ifndef CONFIG_PTE_MARKER_UFFD_WP > /* > * If user requested uffd-wp but not enabled pte markers for > * uffd-wp, then shmem & hugetlbfs are not supported but only > * anonymous. > */ > if ((vm_flags & VM_UFFD_WP) && !vma_is_anonymous(vma)) > return false; > #endif > return vma_is_anonymous(vma) || is_vm_hugetlb_page(vma) || > vma_is_shmem(vma); > } I'm confused. Let me ask in another way: do you mean !VM_SHARED when you say "private"? Both shmem & hugetlb support private mappings for all three modes, afaict. > > Well I never thought anyone would be using soft-dirty with uffd because > > logically uffd-wp was somehow trying to replace it with a better interface, > > hopefully. > > I have heard about some who does (not me). So I do not make it up, > unfortunately. If in any form you can get the reason of using soft-dirty in that use case please kindly share more. I think it could be that uffd-wp is not working as good as soft-dirty in some way but we can think about it when there's a valid use case, so ultimately it's more possible for a full replacement. Sync messages can be a problem and they're indeed slow, soft-dirty is by nature async. But still I'd like to check in case you know. > > > > > If to talk about it, IMHO the most important thing is really not the dirty > > bit but the write bit: even if you leave both the dirty bits cleared (so > > the user specified !WRITE_HINT then we grant write bit only), it means when > > the write happens for sure dirty bit will be set on demand but not > > soft-dirty since we won't generate a page fault at all. AFAICT it'll be a > > false negative. > > > > The old code is safe in that respect on that we always set dirty so we can > > only have false positive (which is acceptable in this case) but not false > > negative (which is not). > > I agree that the PTE should be left RO in this case. I was just pointing > that the user might not be aware of soft-dirty being used, and then it > makes sense to treat the (lack of) write-hint appropriately. Yes please. Thanks for raising this topic btw, I never thought about that side effect. [...] > > Another option is we call can_change_pte_writable() somehow in the > > unprotect branch. > > I don’t think that I got this one. No worry, feel free to ignore it. It's probably not ideal anyway because we need an extra pte_mkwrite() there too when can_change_pte_writable() returns true. > tl;dr: I’ll run some numbers (access when PTE-dirty/clear), address the > aforementioned issues and send v2. Based on the results we can decide > whether it makes sense. That'll be very appreciated. Thanks a lot! -- Peter Xu