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 505C2C74A5B for ; Tue, 21 Mar 2023 12:42:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 822C16B0075; Tue, 21 Mar 2023 08:42:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D37D6B0078; Tue, 21 Mar 2023 08:42:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69B1B6B007B; Tue, 21 Mar 2023 08:42:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5929F6B0075 for ; Tue, 21 Mar 2023 08:42:20 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 1D5E5A10EF for ; Tue, 21 Mar 2023 12:42:20 +0000 (UTC) X-FDA: 80592868440.13.1EFC09F Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf09.hostedemail.com (Postfix) with ESMTP id 3E45C140023 for ; Tue, 21 Mar 2023 12:42:17 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VHb1kWo4; spf=pass (imf09.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679402537; a=rsa-sha256; cv=none; b=sXLfSdjS2NSRXVME63dxlnrHGr8yPsA2m/DsfJVWgv5/t14okmSjgCNMEGPn9LQMcqZQhR DNR2UEibWimPKphqiwljalg1MVy2hXqdYLPlT1T7Zqf3cKxTdZVqQqJNjKKW0MdJ7sl84+ 1EMdrMOK/9OKHmpVCOLRjTL9BRZVy5g= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VHb1kWo4; spf=pass (imf09.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679402537; 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=wHQGfeZ2xpJptwVZ7MFDe7dEmSAqYdL0L9YFqy/icYw=; b=FcgZ8DOwZRlOeEu8xqi2LGT7DooqrXu0bjFamOUsjX90g4CnnKPWnKsgeX5VEw0SdK9UQe DpauBnnDy0myvxvNnGeCUgWYmPYhlrbweumwseDzp2VnoMhDvkO6UqW2D53cmoc4OKsNG+ Ytg0HisXcYJ1x4Qgkr1eqsoNVPIosd4= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6FB39B81673; Tue, 21 Mar 2023 12:42:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52A45C433EF; Tue, 21 Mar 2023 12:42:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679402534; bh=DJXLZL3qhKzSZg0yYA16xG9Xycg6KPkRYGZFn8WH8io=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VHb1kWo4K2q7A8RJ+a3MaCsVbB0HMoAhyUpsj2mqPMF3eqeBeLI/+UgU6QIQjNF7/ Xeqmzcy6PPqUka8X1duBZ3hfNMGq2ndukzPKDawLPp8N/KJNIoviON91Wn+2rffEI2 VV3GXliTpV5VcqAryDSFyY04QYNVuepAnLBjnh2CvhmLZFltie1Pv2SVTPOCiwJg6m qgCb91dg54pggiW1iSzoMdCYna6cATElLFGz1yAjC86VAvyISgHOwiLCal4Vg/ofB3 YcSg4p5MWyi8ntAVr/EgkfBg3J/K7/83iVamyyz5Mx1meJvFGgT2LAxex2b84XDUCA GHNCtAZuWHP4Q== Date: Tue, 21 Mar 2023 14:41:53 +0200 From: Mike Rapoport To: Andrei Vagin Cc: Andrew Morton , Muhammad Usama Anjum , Peter Xu , David Hildenbrand , =?utf-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Danylo Mocherniuk , Paul Gofman , Cyrill Gorcunov , Nadav Amit , Alexander Viro , Shuah Khan , Christian Brauner , Yang Shi , Vlastimil Babka , "Liam R . Howlett" , Yun Zhou , Suren Baghdasaryan , Alex Sierra , Matthew Wilcox , Pasha Tatashin , Axel Rasmussen , "Gustavo A . R . Silva" , Dan Williams , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Greg KH , kernel@collabora.com Subject: Re: [PATCH v11 0/7] Implement IOCTL to get and optionally clear info about PTEs Message-ID: References: <20230309135718.1490461-1-usama.anjum@collabora.com> <20230309115818.170dd5ef2cde7b58b9354ecd@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 3E45C140023 X-Rspamd-Server: rspam01 X-Stat-Signature: a87affkxwhjcze9axzgu8jc776196uic X-HE-Tag: 1679402537-302563 X-HE-Meta: U2FsdGVkX1/1f9lAM4yiZGPWxZMJ0pLGf51nrdS38nev8i3Yyw63+4jfMlD6JfTKe6N4Vr1DX//RDy6UFt7//H7KLjR+Qo/TgzCAg5fb9ZbfEh+ihnij4P7RLdsfbW47SB+t5Xw2NQgi4A4GbYECH7d1DZfR7rHR2th3gg1OcjSKovi7cBxlwpIkP3co5idaKpTSY8C2FzSDNM6yHU8B3nxbfXq0HHwXSD3fliTv/m+DS2qbTLYi75rKdyj44Rba2qqZSVQLggjC85pMEg0YD4GW+pUaSbNisb3uT3NU0iJdgxwR2/XOa1Vp43DyXIBEijLhIPjamyHccvVvFZAfsVaMiUze6bXShOqF3kMSydQ2HAinZbLwKs9ip7zWhJzouHVZnT7gAzwbypPHju7vUoi0YrDHF74P66HVd2zpSrETXHptm8e6v7Tq0yO9WWWrXP9A+E/EfvhsSSSTTufDygvQFCl9Q2M/Z/dHr8UZK7vQzf5Onn7EV5/xSjuLaRxS2Q7WFL08hso+g9V79d3hJYLfStq5DOtGNm44Q3OP8wZCKtngoukWtMbxmBI0rVeWwy6O5/s1x26LOn8y/SuMFXadHoNPoqiNduhUX2FY42KzpDuaqpopipgsHHi2Rk/QMRzRx2b7Q79RAucEUeDz7nrZdR4k+zosEiNzt08VtW2/fJOTXC45QP3wRU25GsEEqdOv93yuwla6Tnk9YS4DKSFcs4yHOwd5FTAaHdqrDvTR0xrom6cJyEz8IxsN7fyPgdvk+43RqKmb1bZBxZNMJEPU1rcvA/uEzJS/UNrP5d2ILgx5pUGbsgspQdNVlTbmXfGfU/8U6Ax00iwmZeFx1sBXN9FU+eZUDfwsx9JF6+8uTkNxzrh6bAO4lssJS49shZCDM7b3Q2YpjVNMoaw/SI/q1nmlOyOT3BCPB3eSpJGG0Efz+NkhgSZULpxSXvx+9VdoqZcOp4kZZ5TGfVB iN9Zaa5I Zp/FlIcOtWO4Fbkezh3QNQrv1ZmtfgFmC92BsTcB1mWP+pjBA4M/29ttxex90TGfpuMFtwdqy3GBrXJPYaxxbcnNapCeWQeGqITwaxALEQaJHX7pb3uIL7wewNEFBcN6LnyhwCWsRr9H9pYstM1RnAfQyD6NSaqb1+aYCcCdjYBcNqk2oIs9HBNbd9qQziL6UX3iKn/RbcSyGlFOicd+RgRl9ilS5jQI1e9pr85bjs/11uAF/l74YZOeOMozCFB/mLwNMoulJTLnjoZtwFY4xnazJM+ggSa4XUk8zu6hNfoqLoaN9S2QtoWAlFWrqc9UVh0cMwBZ/HUfKy5X7PieTsUvMxKB0wvptE+5fmeqy8KHt3BirWy2N6+JtgPMn3qj8hKjB+66T4Uy5Dt3kWvqEQUkElf3om2UoOnKh8yVjIKZy7WM= 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 Mon, Mar 20, 2023 at 11:30:00AM -0700, Andrei Vagin wrote: > On Thu, Mar 9, 2023 at 11:58 AM Andrew Morton wrote: > > > > On Thu, 9 Mar 2023 18:57:11 +0500 Muhammad Usama Anjum wrote: > > > > > The information related to pages if the page is file mapped, present and > > > swapped is required for the CRIU project [5][6]. The addition of the > > > required mask, any mask, excluded mask and return masks are also required > > > for the CRIU project [5]. > > > > It's a ton of new code and what I'm not seeing in here (might have > > missed it?) is a clear statement of the value of this feature to our > > users. > > > > I see hints that CRIU would like it, but no description of how valuable > > this is to CRIU's users. > > Hi Andrew, > > The current interface works for CRIU, and I can't say we have anything > critical with it right now. > > On the other hand, the new interface has a number of significant improvements: > > * it is more granular and allows us to track changed pages more > effectively. The current interface can clear dirty bits for the entire > process only. In addition, reading info about pages is a separate > operation. It means we must freeze the process to read information > about all its pages, reset dirty bits, only then we can start dumping > pages. The information about pages becomes more and more outdated, > while we are processing pages. The new interface solves both these > downsides. First, it allows us to read pte bits and clear the > soft-dirty bit atomically. It means that CRIU will not need to freeze > processes to pre-dump their memory. Second, it clears soft-dirty bits > for a specified region of memory. It means CRIU will have actual info > about pages to the moment of dumping them. > > * The new interface has to be much faster because basic page filtering > is happening in the kernel. With the old interface, we have to read > pagemap for each page. There is still a caveat in using userfaultfd for tracking dirty pages in CRIU because we still don't support C/R of processes that use uffd. > Thanks, > Andrei > > > > > So please spend some time preparing this info. > > > > Also, are any other applications of this feature anticipated? If so, > > what are they? > > > > IOW, please sell this stuff to us! -- Sincerely yours, Mike.