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 53D3DC32771 for ; Wed, 28 Sep 2022 17:24:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6EA6A6B0071; Wed, 28 Sep 2022 13:24:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 69A676B0073; Wed, 28 Sep 2022 13:24:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 562666B0074; Wed, 28 Sep 2022 13:24:49 -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 4797E6B0071 for ; Wed, 28 Sep 2022 13:24:49 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 01E96A110C for ; Wed, 28 Sep 2022 17:24:48 +0000 (UTC) X-FDA: 79962169098.11.8669BBC Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by imf16.hostedemail.com (Postfix) with ESMTP id 7C6C1180004 for ; Wed, 28 Sep 2022 17:24:48 +0000 (UTC) Received: by mail-lf1-f50.google.com with SMTP id i26so21378703lfp.11 for ; Wed, 28 Sep 2022 10:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=dFFDss8ZkTsJUFXPbq77SyHdbR0hvnx58KwhDKqLpSo=; b=ZiTnifmxRkPCeTB4+ebf2uhFYDRQMWouSa5MdgsLfW8vtobqMkhQzBrSicMxVo05OZ qV5w7W26YKEzy6yEw/eAqiyVEbwXW6KJv8Lb3GF+c/fTl8INVzBBw0Nh1Erfo5KGbo2q Lbla69FnR1k7HY//+qqC3+SuDLBnADl7ULIb0V/LKm2AZ0NwsFXiX7AuAgmztZRysimZ QBhYEo3O9TfwoSwnc5j/Lgq7ykw4NYPhAx1W8SLtYc4Z3koD8LdT3TYOPzwauswBnwDU vQi+aO3qq7OYHbxn4HgRuG7X++rq9iFbDMFn3M0cwfg4c3KsSLPweUqjCXVDGE8fQmpA rLEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=dFFDss8ZkTsJUFXPbq77SyHdbR0hvnx58KwhDKqLpSo=; b=dLEtZU7yuBg7sE/4u5YMiTy7rl59jIBbgLJ/MtxjC3y17Ak5W5P+1xX90hX6uPhcWW 1hKXsvGZ48I/S+yA8mV9lKRnxUvT2aRYxnBh9LFH4Aapul2e5qB9073+pjhk9Bdw9isn RK9tkIP6Csdq97v7dHIuaMtwYoXTiVsQ/e0sWNFSW+aeYf1m6yCAyj7Okj0LTvEAPG33 YQx2z3lxFd+6cU+B7R2Z/PYIGZpXeIZxmeRz4E9LLkU46HceAUZL0N5uapVyAt1zbQqj DXBfP8RmjPDQSLIr+sswPgW3bf7ZYq4boAnYKM4J9GBlPXQHzrQlMO0BEF2+P4iKjBIA rQ9g== X-Gm-Message-State: ACrzQf0ho3rjc5pXrw9p+nxsBV7r4vkWIpeAPm4JpwMzUSP/HAf4y/Kd z58I2y+nAstdy32fbg1FDG5kdFTYBhYSYcTw/XI= X-Google-Smtp-Source: AMsMyM7vANgFuHUEO9H9bCKbcXCI+zshpprYVfozSllCNMES2Vlkvl622gA3/aR8WXroRHZciBcE8+bXl70+cAtF1tM= X-Received: by 2002:a05:6512:1047:b0:49f:5309:3a0c with SMTP id c7-20020a056512104700b0049f53093a0cmr13216773lfb.683.1664385886495; Wed, 28 Sep 2022 10:24:46 -0700 (PDT) MIME-Version: 1.0 References: <20220826064535.1941190-1-usama.anjum@collabora.com> <2c8b7116-56e9-3202-c47e-e42078c85793@collabora.com> In-Reply-To: <2c8b7116-56e9-3202-c47e-e42078c85793@collabora.com> From: Andrei Vagin Date: Wed, 28 Sep 2022 10:24:35 -0700 Message-ID: Subject: Re: [PATCH v3 0/4] Implement IOCTL to get and clear soft dirty PTE To: Muhammad Usama Anjum Cc: Jonathan Corbet , Alexander Viro , Andrew Morton , Shuah Khan , "open list:DOCUMENTATION" , open list , "open list:PROC FILESYSTEM" , "open list:MEMORY MANAGEMENT" , "open list:KERNEL SELFTEST FRAMEWORK" , kernel@collabora.com, Gabriel Krisman Bertazi , David Hildenbrand , Peter Enderborg , Greg KH Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664385888; a=rsa-sha256; cv=none; b=wxBDJEMSuk8eVoBWXUSrf4Ze0cuNMFQZU3tLks5pphPTV19UztZfKgj4YrosiaRoZhjYzF 7i9agWTTVxMlYJmuyYjSJ5L70yhO199w6i5CP8fuvHgKWzJiMdP33NI2NDh7HfXp+2+dHE btVIxKdE00dhPVtf/aJ46BUeGY76ZAk= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZiTnifmx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of avagin@gmail.com designates 209.85.167.50 as permitted sender) smtp.mailfrom=avagin@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664385888; 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=dFFDss8ZkTsJUFXPbq77SyHdbR0hvnx58KwhDKqLpSo=; b=tcQV0wpw7B9Nby6E03GndYKFApw3LMvVO+MwG+B8fzc44sZ7BkadtRSRwCiTUL+OClck6y rdJNq1EfslD/jENup2PWUwUW3JNnlpJu8fcx3F6Ln8B0CQ3ZRGRFmtqm/+3DSRFXb4/MMN xS407H7Wv3JZs7dghTlf0mBaFyh137U= X-Rspamd-Queue-Id: 7C6C1180004 X-Rspam-User: Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZiTnifmx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of avagin@gmail.com designates 209.85.167.50 as permitted sender) smtp.mailfrom=avagin@gmail.com X-Rspamd-Server: rspam03 X-Stat-Signature: 3k3soe1x39yntimdpq3n47zotsw7c1ii X-HE-Tag: 1664385888-882323 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, Sep 21, 2022 at 11:26 AM Muhammad Usama Anjum wrote: > > Hi, > > Thank you for reviewing. > > On 9/19/22 7:58 PM, Andrei Vagin wrote: > >> This ioctl can be used by the CRIU project and other applications which > >> require soft-dirty PTE bit information. The following operations are > >> supported in this ioctl: > >> - Get the pages that are soft-dirty. > > > > I think this interface doesn't have to be limited by the soft-dirty > > bits only. For example, CRIU needs to know whether file, present and swap bits > > are set or not. > These operations can be performed by pagemap procfs file. Definitely > performing them through IOCTL will be faster. But I'm trying to add a > simple IOCTL by which some specific PTE bit can be read and cleared > atomically. This IOCTL can be extended to include other bits like file, > present and swap bits by keeping the interface simple. The following > mask advice is nice. But if we add that kind of masking, it'll start to > look like a filter on top of pagemap. My intention is to not duplicate > the functionality already provided by the pagemap. One may ask, then why > am I adding "get the soft-dirty pages" functionality? I'm adding it to > complement the get and clear operation. The "get" and "get and clear" > operations with special flag (PAGEMAP_SD_NO_REUSED_REGIONS) can give > results quicker by not splitting the VMAs. This simple interface is good only for a limited number of use-cases. The interface that I suggest doesn't duplicate more code than this one, but it is much more universal. It will be a big mess if you add a separate API for each specific use-case. > > > > > I mean we should be able to specify for what pages we need to get info > > for. An ioctl argument can have these four fields: > > * required bits (rmask & mask == mask) - all bits from this mask have to be set. > > * any of these bits (amask & mask != 0) - any of these bits is set. > > * exclude masks (emask & mask == 0) = none of these bits are set. > > * return mask - bits that have to be reported to user. > > > >> - Clear the pages which are soft-dirty. > >> - The optional flag to ignore the VM_SOFTDIRTY and only track per page > >> soft-dirty PTE bit > >> > >> There are two decisions which have been taken about how to get the output > >> from the syscall. > >> - Return offsets of the pages from the start in the vec > > > > We can conside to return regions that contains pages with the same set > > of bits. > > > > struct page_region { > > void *start; > > long size; > > u64 bitmap; > > } > > > > And ioctl returns arrays of page_region-s. I believe it will be more > > compact form for many cases. > Thank you for mentioning this. I'd considered this while development. > But I gave up and used the simple array to return the offsets of the > pages as in the problem I'm trying to solve, the dirty pages may be > present amid non-dirty pages. The range may not be useful in that case. This is a good example. If we expect more than two consequent pages on average, the "region" interface looks more prefered. I don't know your use-case, but in the case of CRIU, this assumption looks reasonable. > Also we want to return only a specific number of pages of interest. The > following paragraph explains it. > > > > >> - Stop execution when vec is filled with dirty pages > >> These two arguments doesn't follow the mincore() philosophy where the > >> output array corresponds to the address range in one to one fashion, hence > >> the output buffer length isn't passed and only a flag is set if the page > >> is present. This makes mincore() easy to use with less control. We are > >> passing the size of the output array and putting return data consecutively > >> which is offset of dirty pages from the start. The user can convert these > >> offsets back into the dirty page addresses easily. Suppose, the user want > >> to get first 10 dirty pages from a total memory of 100 pages. He'll > >> allocate output buffer of size 10 and the ioctl will abort after finding the > >> 10 pages. This behaviour is needed to support Windows' getWriteWatch(). The > >> behaviour like mincore() can be achieved by passing output buffer of 100 > >> size. This interface can be used for any desired behaviour. Now, it is more clear where this interface came from. It repeats the interface of Windows' getWriteWatch. I think we have to look wider. The interface that reports regions will be more efficient for many use-cases. As for getWriteWatch, it will require a bit more code in user-space, but this code is trivial. Thanks, Andrei