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 813E7C636D7 for ; Thu, 23 Feb 2023 08:42:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 180926B0085; Thu, 23 Feb 2023 03:42:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 130AF6B0087; Thu, 23 Feb 2023 03:42:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F14B56B0088; Thu, 23 Feb 2023 03:42:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E1DDD6B0085 for ; Thu, 23 Feb 2023 03:42:12 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A8229AB8DF for ; Thu, 23 Feb 2023 08:42:12 +0000 (UTC) X-FDA: 80497914504.18.C0A3E8D Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf26.hostedemail.com (Postfix) with ESMTP id BC09A14000F for ; Thu, 23 Feb 2023 08:42:10 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Sql1dwoA; spf=pass (imf26.hostedemail.com: domain of emmir@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=emmir@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677141730; 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=U9SuIbp75g+UlIghsWi+4N5mCZqO2tDPQ4lhx9i41C0=; b=NlL26PniutIRI0U4ouOEqHverbJQMVhEVWnizxYnDCcw0bO6HsG7CgxuztRbZzNSReX8// Ps0eckKaz2mfWVbiJfvAXbZWzGSPzsRTdytW38pzfX2VhNgOlVnKjkTuhYf1cTu71OhkUg +vd+sRxCbV8rm2wrp2vjnkwf9gcQC34= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Sql1dwoA; spf=pass (imf26.hostedemail.com: domain of emmir@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=emmir@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677141730; a=rsa-sha256; cv=none; b=LIp1Fpjmcr83bZNGKSNqLoXzC9rIQiP0qyj5HIV49aE6R8KA70vHuHUB6JXIXMQ/Kv2Q0Z n4hE1QUNWEwTYuSIaS1W2AJY2qMfSloNka9Dlgj1Teh7AEFEhvZYJ6z0Y71y5B0Gb2z40r F2X/USmwvW987zR3BvQn7xK1G8UYBA0= Received: by mail-ed1-f41.google.com with SMTP id f13so38950832edz.6 for ; Thu, 23 Feb 2023 00:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=U9SuIbp75g+UlIghsWi+4N5mCZqO2tDPQ4lhx9i41C0=; b=Sql1dwoABX35nY3bSJPdFEkz/lY1Wf1brUMaBci/7FtKBzXn/BMxeek+zyRyomMiWY 5dupSdb3TGw5OO224ZAGfMvyusV7BQdQeO88uNW0NV3NDIaWw+uSogw0k8VAHmQEKMed zo86n9U3eXIGSgrxncXPuhKKUjfGnpATX1tvGtK6AMuus63fGGorBVMxhOmT3Ond2XfR mHAI9ZH9vObqAwvvnBht2HdGwRfzsMZNXznLZ+j5m0UlujSqxW75Xk/XSOpRiHV1P97q ao5BfNXrTeBJZdKNKUDMf5n6sY2o2qsHlmG3VwhhybYJpkEuFpQnQ6gZBJJsQFHtzKwV y4bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=U9SuIbp75g+UlIghsWi+4N5mCZqO2tDPQ4lhx9i41C0=; b=8P+TXaxxV2/sz3mnMjFYIbLU4gl0YL70YOv6IUSw2Y1uB6xcojtHolCsMb7PZiJGFi a+/x+sgogZHIRmYcml9v4yRjRQBZVzhfj3QYK2l6boRSb6HoFi1L2wQg1hGlgrPxGiRV rBUuBQx+FvlNtylrQWORNoxjwsGOwLA7Z2i10qiJrk43ia1N3KE5SNVcJuzCjriEkqzd QKZqjYW2tB3Y8xMjr1/lChodhYRsadlghA+L7KrMBsb56vOCeMEQAo1yhEOEImazv24R mjG3NLH6psYtsbNKfTlfIxGjpnYSNlKKFEXqmA+mesDwHWCbFLJ5h5pPt+tYjd4rloN3 ixCA== X-Gm-Message-State: AO0yUKUOFb4iHmWx3KUhvnZf2dfgxKFEyXBV7jRE9+jjmh+0bG5eBlBR W7aDMJ4wch4s+m0glAaKRydry/R82/AQOYfvIO7I3A== X-Google-Smtp-Source: AK7set+0RrEHvhjbLGutaoQmuwIf40OYH9vAIuKbdgW+AtlRh/s1sKEeENFlG0624jU6i4TLccJorj7cYb6fcTRAwOA= X-Received: by 2002:a50:8a92:0:b0:4ae:e606:432f with SMTP id j18-20020a508a92000000b004aee606432fmr6080742edj.0.1677141729090; Thu, 23 Feb 2023 00:42:09 -0800 (PST) MIME-Version: 1.0 References: <20230202112915.867409-1-usama.anjum@collabora.com> <20230202112915.867409-4-usama.anjum@collabora.com> <36ddfd75-5c58-197b-16c9-9f819099ea6d@collabora.com> <6d2b40c6-bed9-69a6-e198-537b50953acd@collabora.com> <473b32fd-24f9-88fd-602f-3ba11d725472@collabora.com> In-Reply-To: <473b32fd-24f9-88fd-602f-3ba11d725472@collabora.com> From: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Date: Thu, 23 Feb 2023 09:41:57 +0100 Message-ID: Subject: Re: [PATCH v10 3/6] fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about PTEs To: Muhammad Usama Anjum Cc: Andrei Vagin , Mike Rapoport , Nadav Amit , David Hildenbrand , Andrew Morton , Paul Gofman , Cyrill Gorcunov , Alexander Viro , Shuah Khan , Christian Brauner , Yang Shi , Vlastimil Babka , "Liam R . Howlett" , Yun Zhou , Suren Baghdasaryan , Alex Sierra , Peter Xu , 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, Danylo Mocherniuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: fqdhkfuzz9oa5x1zgur75qaeog6muyp9 X-Rspamd-Queue-Id: BC09A14000F X-HE-Tag: 1677141730-460121 X-HE-Meta: U2FsdGVkX19lYb7lgFawyAN/RBjn97o7KOJFAezfoCT5rv3fKqE5jO1WFEgbItIP8rVTL0/PMNxb6Sk7wzaOWzXZdPrmRHym0HqoGrFCgeZbmslcAhy2LpJsAQxR55ngQ6DujNwk5ZPUS05DE9IP6pTTuK7VQwgCkLYkqG3rJ7M4l1OEt143CCacT8obbK3xe3ly30hzndXvgow6NRZ4p4nje1SV8bPHOOHoqcAPWvuPQuAZzCcUhhjQpd0SlJNRb3JKNXkeELmMvudk831X5cL5c9KWqD4wm/J2+yTfzRUx1GjjZV/3tO4gcQMJVDQxjMorIaTLCFb4sQe07uRUfPiaaW6AofFj/b03OU+Ql6CxupvhecqT/RgU44rnpiZy0hYP+8xWrlBXw8TkQUobwpbGWVZHe0m4M7hFSKhUrhRx/WqFeZDZdTy/5NX8NvZXUAZI1pWo0NWpqD1VAwxIpxwNvpJnSjFMNrxvQxEUJoKvgwJ4ov6h6PefnOePN2Op2m+AhsfXtnX0GS+vDRiT8LCPfd1bGgZ1RFOxN6RSDQ/EH/U+i3OyMahI9d4hFmheeuTDuQzVkoPJnr4ekpkJpzDbKTJDSapkuIk9nP1P7ps8piRv0ePDKBkBeRRrviVY/hXhgy8qk14Fk5WBoK0Ot1KsD1PCkc7DQ2egBJ0/W9/0FPs7NrObD9ydMgXLQVGbrEZHYuhjtO+2GlO5of3GYZMBTjPS34OlD3VDd5avtvOuMqHdtH5VQC6TfV8AjPEVq5C5U9mxfvbQmovv7RpBYX/nOkvrGYKr1xOHkUvxuJ4TVd1YucdxyajeXfsgSGzj3WR79ETSwLiwpECYqzfec3RaJhv6oBCbFrVw8kFhg+nnB/j84Q2kqFm/mlXxOUYhyuK6Cxc5th9jTMe27928J4JRe+k2vcQrfSP22xUKPixLNvv5ivfSPnJ5RDTGmo1UFamXr7LV6LQTUN5Jrnv 959/odyp nThLUrEgsKlMOZzu3eYqtJ+7e7xeZmtj2mWwq60nSCbUBzN2+vjlreRDpVeVnT+VTH+30Y72IwpdpjnKivTrG7GKoBy3fDey+fLpOjFKR6NBYhTU8ZBf29gFh8pYYcJsDTNqvDUhcTiiaScKlPh0P+7vXwQ2+4iiSoiTOdig4FU7w4lscTz8i303yTlCGpLonim28FWFy1XzBdrspDcv9pz0maxpiqqPt9HTpbWPYpT7Y3Uwlm2fBGYwQV2SbrO/Mfif3ufp2bdw6PhxVprj7joVqKWd3TlJHXW7BNQfrAw9epvqZTY8acrgz8Z/O1bAHhB7q5Nq51f0c0uM6Ffbkn/5IUkKywAnclUx4qnMylR0iEDKTMc/nFWlw0w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000011, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 23 Feb 2023 at 07:44, Muhammad Usama Anjum wrote: > > On 2/22/23 4:48=E2=80=AFPM, Micha=C5=82 Miros=C5=82aw wrote: > > On Wed, 22 Feb 2023 at 12:06, Muhammad Usama Anjum > > wrote: [...] > >>>>> BTW, I think I assumed that both conditions (all flags in > >>>>> required_flags and at least one in anyof_flags is present) need to = be > >>>>> true for the page to be selected - is this your intention? > >>>> All the masks are optional. If all or any of the 3 masks are specifi= ed, the > >>>> page flags must pass these masks to get selected. > >>> > >>> This explanation contradicts in part the introductory paragraph, but > >>> this version seems more useful as you can pass all masks zero to have > >>> all pages selected. > >> Sorry, I wrote it wrongly. (All the masks are not optional.) Let me > >> rephrase. All or at least any 1 of the 3 masks (required, any, exclude= ) > >> must be specified. The return_mask must always be specified. Error is > >> returned if all 3 masks (required, anyof, exclude) are zero or return_= mask > >> is zero. > > > > Why do you need those restrictions? I'd guess it is valid to request a > > list of all pages with zero return_mask - this will return a compact > > list of used ranges of the virtual address space. > At the time, we are supporting 4 flags (PAGE_IS_WRITTEN, PAGE_IS_FILE, > PAGE_IS_PRESENT and PAGE_IS_SWAPPED). The idea is that user mention his > flags of interest in the return_mask. If he wants only 1 flag, he'll > specify it. Definitely if user wants only 1 flag, initially it doesn't ma= ke > any sense to mention in the return mask. But we want uniformity. If user > want, 2 or more flags in returned, return_mask becomes compulsory. So to > keep things simple and generic for any number of flags of interest > returned, the return_mask must be specified even if the flag of interest = is > only 1. I'm not sure why do we want uniformity in the case of 1 flag? If a user specifies a single required flag, I'd expect he doesn't need to look at the flags returned as those will duplicate the information from mere presence of a page. A user might also require a single flag, but want all of them returned. Both requests - return 1 flag and return 0 flags would give meaningful output, so why force one way or the other? Allowing two will also enable users to express the intent: they need either just a list of pages, or they need a list with per-page flags - the need would follow from the code structure or other factors. > >>>> After taking a while to understand this and compare with already pre= sent > >>>> flag system, `negated flags` is comparatively difficult to understan= d while > >>>> already present flags seem easier. > >>> > >>> Maybe replacing negated_flags in the API with matched_values =3D > >>> ~negated_flags would make this better? > >>> > >>> We compare having to understand XOR vs having to understand ordering > >>> of required_flags and excluded_flags. > >> There is no ordering in current masks scheme. No mask is preferable. F= or a > >> page to get selected, all the definitions of the masks must be fulfill= ed. > >> You have come up with good example that what if required_mask =3D > >> exclude_mask. In this case, no page will fulfill the criterion and hen= ce no > >> page would be selected. It is user's fault that he isn't understanding= the > >> definitions of these masks correctly. > >> > >> Now thinking about it, I can add a error check which would return erro= r if > >> a bit in required and excluded masks matches. Would you like it? Lets = put > >> this check in place. > >> (Previously I'd left it for user's wisdom not to do this. If he'll spe= cify > >> same masks in them, he'll get no addresses out of the syscall.) > > > > This error case is (one of) the problems I propose avoiding. You also > > need much more text to describe the requred/excluded flags > > interactions and edge cases than saying that a flag must have a value > > equal to corresponding bit in ~negated_flags to be matched by > > requried/anyof masks. > I've found excluded_mask very intuitive as compared to negated_mask which > is so difficult to understand that I don't know how to use it correctly. > Lets take an example, I want pages which are PAGE_IS_WRITTEN and are not > PAGE_IS_FILE. In addition, the pages must be PAGE_IS_PRESENT or > PAGE_IS_SWAPPED. This can be specified as: > > required_mask =3D PAGE_IS_WRITTEN > excluded_mask =3D PAGE_IS_FILE > anyof_mask =3D PAGE_IS_PRESETNT | PAGE_IS_SWAP > > (a) assume page_flags =3D 0b1111 > skip page as 0b1111 & 0b0010 =3D true > > (b) assume page_flags =3D 0b1001 > select page as 0b1001 & 0b0010 =3D false > > It seemed intuitive. Right? How would you achieve same thing with negated= _mask? > > required_mask =3D PAGE_IS_WRITTEN > negated_mask =3D PAGE_IS_FILE > anyof_mask =3D PAGE_IS_PRESETNT | PAGE_IS_SWAP > > (1) assume page_flags =3D 0b1111 > tested_flags =3D 0b1111 ^ 0b0010 =3D 0b1101 > > (2) assume page_flags =3D 0b1001 > tested_flags =3D 0b1001 ^ 0b0010 =3D 0b1011 > > In (1), we wanted to skip pages which have PAGE_IS_FILE set. But > negated_mask has just masked it and page is still getting tested if it > should be selected and it would get selected. It is wrong. > > In (2), the PAGE_IS_FILE bit of page_flags was 0 and got updated to 1 or > PAGE_IS_FILE in tested_flags. I require flags PAGE_IS_WRITTEN=3D1, PAGE_IS_FILE=3D0, so: required_mask =3D PAGE_IS_WRITTEN | PAGE_IS_FILE; negated_flags =3D PAGE_IS_FILE; // flags I want zero I also require one of PAGE_IS_PRESENT=3D1 or PAGE_IS_SWAP=3D1, so: anyof_mask =3D PAGE_IS_PRESENT | PAGE_IS_SWAP; Another case: I want to analyse a process' working set: required_mask =3D 0; negated_flags =3D PAGE_IS_FILE; anyof_mask =3D PAGE_IS_FILE | PAGE_IS_WRITTEN; -> gathering pages modified [WRITTEN=3D1] or not backed by a file [FILE=3D0= ]. To clarify a bit: negated_flags doesn't mask anything: the field inverts values of the flags (marks some "active low", if you consider electronic signal analogy). Best Regards Micha=C5=82 Miros=C5=82aw