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 4A6A4C4332F for ; Wed, 23 Nov 2022 14:11:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A8C606B0071; Wed, 23 Nov 2022 09:11:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A3C8F6B0073; Wed, 23 Nov 2022 09:11:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DCD36B0074; Wed, 23 Nov 2022 09:11:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7AF616B0071 for ; Wed, 23 Nov 2022 09:11:38 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1906C1A05E0 for ; Wed, 23 Nov 2022 14:11:37 +0000 (UTC) X-FDA: 80164895034.12.97E6B2F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf03.hostedemail.com (Postfix) with ESMTP id 26DC120012 for ; Wed, 23 Nov 2022 14:11:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669212694; 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: in-reply-to:in-reply-to:references:references; bh=8/DTsoiDdjjsRtV9pwPMMoAHlpx48KJLm5OuDCWlE6M=; b=ImN9HtjAGd1kycPpbn2VPlQDfoA5FI4JEG2SZK0CojefJ88vThg1QNnXwTp6PY4rABU2Gu ZEf+XQ4r7fouAxiubqpQ2rsxekt0MJYPJO2mwWgaLLspNH464R2JgUQHEtWBhWMVE/l/6c 4zRMQy0mAAbJS4SJP4gju+XbG4EY8hQ= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-657-N7YVeYRfOOCmOWv5f490yw-1; Wed, 23 Nov 2022 09:11:33 -0500 X-MC-Unique: N7YVeYRfOOCmOWv5f490yw-1 Received: by mail-qv1-f70.google.com with SMTP id b1-20020a0cfb41000000b004c690b1dd8bso14936920qvq.6 for ; Wed, 23 Nov 2022 06:11:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8/DTsoiDdjjsRtV9pwPMMoAHlpx48KJLm5OuDCWlE6M=; b=DPaC9QU8y0HPVUHMkuiNjnF/MI3s11fC7yKTzPxfr4AuySZZAJM34bv9kDCtQcbl6V uRdLfsq+5aLZo0JKzJjC2UDftnLfbOMFbdC+DhgaAK5vYfPlO7eLu5YwY3uhRKJp+DJJ NoiRMhT1YKD8+vBXP4QQxZfaLVvbA0pQ3ur17zIE+NUpL7Dsll3Vll9Zj5+yt8j+v2iI L03sXkasZw2dg+KsS4V4slE1h49vlGFtkEXlevXbnFNzjyuWek4i0hbNYEdixcvlL2xI yaBfd8s7hl1NLqCWuAToHf3JR9dbae3WhHp/vkuXvdiAPvzmLJN9yN3+HX5vYIuLeUtL hwfg== X-Gm-Message-State: ANoB5pkJfYcoDer8tAp3nl8JpV9aNCLZIaztZoRSub5Q+Us/CtnE0anu 30gylAGP0poNbNvgIxqBMHSE8YMVWplkVVw+YkZBEbU6c0i4zJSlUqEgvM48E8vPcBo27k+oIn+ 6OyDidhhTaV8= X-Received: by 2002:a05:620a:215c:b0:6fa:937f:61d4 with SMTP id m28-20020a05620a215c00b006fa937f61d4mr10724840qkm.280.1669212692629; Wed, 23 Nov 2022 06:11:32 -0800 (PST) X-Google-Smtp-Source: AA0mqf6SUx6m2TjrGKG87f9C4JXPILTeMPN0Mxipek+6Q+wnWntXqutLB5B+k6aNyyqF0614O+yLqQ== X-Received: by 2002:a05:620a:215c:b0:6fa:937f:61d4 with SMTP id m28-20020a05620a215c00b006fa937f61d4mr10724802qkm.280.1669212692303; Wed, 23 Nov 2022 06:11:32 -0800 (PST) Received: from x1n (bras-base-aurron9127w-grc-46-70-31-27-79.dsl.bell.ca. [70.31.27.79]) by smtp.gmail.com with ESMTPSA id n30-20020ac81e1e000000b003a50b9f099esm9980897qtl.12.2022.11.23.06.11.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Nov 2022 06:11:31 -0800 (PST) Date: Wed, 23 Nov 2022 09:11:30 -0500 From: Peter Xu To: Muhammad Usama Anjum Cc: =?utf-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Andrei Vagin , Danylo Mocherniuk , Alexander Viro , Andrew Morton , Suren Baghdasaryan , Greg KH , Christian Brauner , Yang Shi , Vlastimil Babka , Zach O'Keefe , "Matthew Wilcox (Oracle)" , "Gustavo A. R. Silva" , Dan Williams , kernel@collabora.com, Gabriel Krisman Bertazi , David Hildenbrand , Peter Enderborg , "open list : KERNEL SELFTEST FRAMEWORK" , Shuah Khan , open list , "open list : PROC FILESYSTEM" , "open list : MEMORY MANAGEMENT" , Paul Gofman , Andrea Arcangeli Subject: Re: [PATCH v6 0/3] Implement IOCTL to get and/or the clear info about PTEs Message-ID: References: <20221109102303.851281-1-usama.anjum@collabora.com> MIME-Version: 1.0 In-Reply-To: <20221109102303.851281-1-usama.anjum@collabora.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669212696; a=rsa-sha256; cv=none; b=0nXSIF2uNqYCFrZ22XXCACgkT/n56sXNj8F/qru4qJX7zY7FqJmZO0ybMScgZ7MdDwByhC aEa9Du9nORLuJrQ14tte0On8pVD/hWi5gr12aLpjvZWJ0hQLm+BcWMwUyShSthyo9/+bP2 wntvYB3WQkkOB4PXMyrBJTTDKxC+7uI= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ImN9HtjA; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf03.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669212696; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8/DTsoiDdjjsRtV9pwPMMoAHlpx48KJLm5OuDCWlE6M=; b=LXKcKOwVPT07+WUaptoxIoTx13jVDjQjJ7cyjG/kpAdDLy32+rg1rIiGTzK3VoffsezFhE BnAj4W8g2ds/h69US0FTK8BomqY8HdXL5yyciPGuy/3PCYJ8FgAD0G07E+aUFVb3F2bCDI qRejuX/UOY1c4orDR6Ux1vfdsOCF+KQ= Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ImN9HtjA; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf03.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com X-Stat-Signature: 66bzj3rp85rc3xoh8xmf9p4xa8m9bxxn X-Rspamd-Queue-Id: 26DC120012 X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1669212694-421491 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 Wed, Nov 09, 2022 at 03:23:00PM +0500, Muhammad Usama Anjum wrote: > Soft-dirty PTE bit of the memory pages can be read by using the pagemap > procfs file. The soft-dirty PTE bit for the whole memory range of the > process can be cleared by writing to the clear_refs file. There are other > methods to mimic this information entirely in userspace with poor > performance: > - The mprotect syscall and SIGSEGV handler for bookkeeping > - The userfaultfd syscall with the handler for bookkeeping Userfaultfd is definitely slow in this case because it needs the messaging roundtrip that happens in two different threads synchronously, so at least more schedule effort even than mprotect. I saw the other patch on vma merging with SOFTDIRTY, didn't look deeper there but IIUC it won't really help much if the other commit (34228d47) can't be reverted then it seems to help nothing. And, it does looks risky to revert that because in the same commit it mentioned the case where one can clear ref right before a vma merge, so definitely worth more thoughts and testings, which I agree with you. I'm thinking whether the vma issue can be totally avoided. For example by providing an async version of uffd-wp. Currently uffd-wp must be synchronous and it'll be slow but it services specific purposes. And this is definitely not the 1st time any of us thinking about uffd-wp being async, it's just that we need to solve the problem of storage on the dirty information. Actually we can also use other storage form but so far I didn't think of anything that's easy and clean. Current soft-dirty bit also has its defects (e.g. the need to take mmap lock and walk the pgtables), but that part will be the same as soft-dirty for now. Now I'm wildly thinking whether we can just reuse the soft-dirty bit in the ptes already defined. The GET interface could be similar as proposed here, or at least a separate issue. So _maybe_ we can have a feature (bound to the uffd context) for uffd that enables async uffd-wp, in which case the wr-protect fault is not sending any message anymore (nor enqueuing) but instead setting the soft-dirty then quickly resolving the write bit immediately and continue the fault. Clearing of the soft-dirty bit needs to be done in UFFDIO_WRITEPROTECT alongside of clearing uffd-wp bit. So on that part the current GET+CLEAR interface for pagemap may need to be replaced. And frankly, it feels weird to me to allow change mm layout in pagemap ioctls.. With this we can keep the pagemap interface to only fetch information, like before. A major benefit of using uffd is that uffd is by nature pte-based, so no fiddling with vma needed at all. Firstly, no need to worry about merging vmas with tons of false positives. Meanwhile, one can wr-protect in page-size granule easily. All the wr-protect is not governed by vma flag anymore but based on uffd-wp flag, so no extra overhead too on any page that the monitor is not interested. There's already infrastructure code for persisting uffd-wp bit, so it'll naturally work similarly for an async mode if to come to the world. It's just that we'll also need to consider exclusive use of the bit, so we'll need to fail clear_refs on vmas where we have VM_UFFD_WP and also the async feature enabled. I would hope that's very rare, but worth thinking about its side effect. The same will need to apply to UFFDIO_REGISTER on async wp mode when soft-dirty enabled, we'll need to bailout too. Said that, this is not a suggestion of a new design, but just something I thought about when reading this, and quickly writting this down. Thanks, -- Peter Xu