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 6CA86C7EE23 for ; Thu, 8 Jun 2023 10:05:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E96888E0003; Thu, 8 Jun 2023 06:05:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E45B38E0002; Thu, 8 Jun 2023 06:05:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D0C728E0003; Thu, 8 Jun 2023 06:05:26 -0400 (EDT) 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 BD2C38E0002 for ; Thu, 8 Jun 2023 06:05:26 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 977961A01C7 for ; Thu, 8 Jun 2023 10:05:26 +0000 (UTC) X-FDA: 80879148252.26.BBF3D98 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf01.hostedemail.com (Postfix) with ESMTP id C630040014 for ; Thu, 8 Jun 2023 10:05:24 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=otejgLvW; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=lokeshgidra@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686218724; 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=xqGEdhtRpLQfdvhmpdvDRNJ/6MqO8TWpTquq8lMiOyo=; b=21njEVM1Oe/TFJd6pRwz9xQEcVe4+l9svqHkXk12mJH7Ytf4qc6gXjuTvBn2LP0Z3r4AVR F7y4aLAuuDRmMmRPNwhiVwQXp6DqUQfpE8CDsAgCOhfeXjxTtWnxXu5OHTJw3sse0A31To uU3S6t8xiyRjCNfzbc3VT3fTB1jHLr4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=otejgLvW; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=lokeshgidra@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686218724; a=rsa-sha256; cv=none; b=3KLq1Pe1FSPGlkskl2C5cHF0FeEDA25gVUEUsXtQBXZiSEo1GflBbrrri7vLsbWivZtJYu LLK1niylAOvK7wgeQXgg1qpW7hm0IHdsV8FVrjQVFgFHCmOJI8CZj8lhx+euK1XAjOTgWd Ap/jAZmKSVBF3uzJdHozSrc5TLmjJ/A= Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-51478f6106cso696003a12.1 for ; Thu, 08 Jun 2023 03:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686218723; x=1688810723; 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=xqGEdhtRpLQfdvhmpdvDRNJ/6MqO8TWpTquq8lMiOyo=; b=otejgLvWNENioG+/YiRpppJD8VZv1cF8TIAYPXrelh2AQKN7n3KdNQd9VPa6MlVvSO v3CEFVRyL102gYFN/0iT995Yaw64gN+uaWPnyarm0CWpx2U3hGHTCSdM55zwfn99XCKt VFkPC7PZCMYqj/Jgkrmqb1IRVjl3yFOlt6e4f2KoCO1QTu6R5AhVaeNRb4Qf0Xi0qKO6 9geyvGwBaogFuUy9ky3C70V83gls8qREubwz8xN2vVtafPOBnmc9kw0A2Ee/x4veR8yl PGaf9d54s7BVVTmcFxYY05d0XuYJt1y6ydTzKWeqWhJzao0Ys3O5+bAynTGPvESxjLID W7bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686218723; x=1688810723; 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=xqGEdhtRpLQfdvhmpdvDRNJ/6MqO8TWpTquq8lMiOyo=; b=QZvn3CVuaelloKGwSZTKvq2S3KCB9MZ1p1FXnonWGDakArsTiaH+PVQCmHCN2jo6xD bwdKsXsfGdaGz4QszpAZKCfRhvBxnHUA4maMy/iUT1wyDntVgODhL5/FZ5+1zlhemXgb jUrPIlMQJUrvgkC/LhkeYlnJn6WgM1tzBCfPKTWMvyWzSocCw8c++7DBeTC3EOfV/WUE 15JQqDbFMrSn8i7RVCGBvfpkY1jqKK5xhYgqO9rEMoQjbwpkcFWegx8V6m4wVWtYmHib OhUbRrXfl8cFZ+cbsH1ShG9uWW3jj7LTwfB1tz6dYqkGcxiHlkUWd7HnSQDkhw8SeWuj 9vrQ== X-Gm-Message-State: AC+VfDxG7U+Xke3fBlRn9vYhvRD5MMrCREEpnR/lf/qsyTTyju4xdP0e tBaNbFRcp6L4LTdajRx+eUCXODYqtN4VIkvS+T7ACw== X-Google-Smtp-Source: ACHHUZ4JzWuVV63DhWdyJzBtDB0n669XnvENSEa/YND+EFl/YRLa+JcprO/yrxbiPbpMCv/RXjFd9z3bUIQdX0LVwMI= X-Received: by 2002:a17:907:9404:b0:977:cdd6:6a5c with SMTP id dk4-20020a170907940400b00977cdd66a5cmr7237275ejc.10.1686218722765; Thu, 08 Jun 2023 03:05:22 -0700 (PDT) MIME-Version: 1.0 References: <27ac2f51-e2bf-7645-7a76-0684248a5902@redhat.com> <3059388f-1604-c326-c66f-c2e0f9bb6cbf@redhat.com> <6403a950-7367-0b00-8cd5-2f0a32dac953@suse.cz> In-Reply-To: From: Lokesh Gidra Date: Thu, 8 Jun 2023 03:05:11 -0700 Message-ID: Subject: Re: RFC for new feature to move pages from one vma to another without split To: Suren Baghdasaryan Cc: Vlastimil Babka , Peter Xu , David Hildenbrand , Axel Rasmussen , Andrew Morton , "open list:MEMORY MANAGEMENT" , linux-kernel , Andrea Arcangeli , "Kirill A . Shutemov" , "Kirill A. Shutemov" , Brian Geffon , Kalesh Singh , Nicolas Geoffray , Jared Duke , android-mm , Blake Caldwell , Mike Rapoport Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: C630040014 X-Stat-Signature: m9wru4ocdqigax8w17f1c84gf9bk1hmz X-Rspam-User: X-HE-Tag: 1686218724-677824 X-HE-Meta: U2FsdGVkX18kjgtG8eVTkDUOp2z79G55n3wmX3xirx8C+TRq/7lr82Fv4cC2XGQEDB53o3isteESRX5UleMw08DMN9v7T/VJtZu+alHIaX7tLZll46/oJucV3M7wM1FnlQS2015KtcNBycmMgiyKUSR4/KhBqB1OeViDsHGYwXVqcK3xYRBXL/bYRArmaan3pMpftuoZCAbKB6gCHClMdsgrMotINM2XkRUYBlxrWzt/XofKLkSmiNkpfiXQ5kzvVmfRFMGY1hRTD0spgYaPmGtWQv4Bocq9vquoW+0wC6dw68zsXNl/5SwEgU+rnh4GJG38VXp3zynLmEVgCHH4rDwKoVJWYx5TIAby9EijFNaUV0l3a2ZO+yxSjYC+PZyg7bS21YhqeExH7T8G1/xa15w6NV80CbctbiSJHH1HCjDrelpoCRqD8NM6/epVgGBp9Djgi5maMnhVo3tqAmsVdZrhHQ3eaDqhpZ6lPZk8ZkjgPfJVuvxy1JXDUfm4Q+SiqO5VN+940ipLk6l/gIoXmwb9DSlfpSf0poDonayKcyY7l4fxiUVHsG3+33dnuewwGqxDMnqzGHOU4QJVy86IZo0As7unzG+DrD88NCB2AksH7YGvuln8viAmugXKDv8zk7amRF8t1rWcg0IC0LrVc1AI2b3ZyKnkGHx7lVKCQVOfwTCcPQD0tVRkpZZTiF5iQrEq/ELgCqtnCNY2CJ8NCwCwApwEnkSUgptWXwyUBUgVd+JXniWmI2cyBUfJus/GzB/6HIoa2Cq3569ai9gta96FfDh8h57HoKEdCBbg9nAIDCnNeLAj7fRLzXlM9wfwZ12UGqV4SC2E06SKKSBfWIxw3i/Xt37f+Hhp3F0xed7/wJ46H6u8ZgUBgYp4GQ3USs6GNHChO6OiqL/07y0OT5a/H6mlv9XSTBtFA3xsJbFUfJzhH9I7cP+j4vcXuOW4iDVdL7D84FJiyKWKC5M h4DdPt+H fTRRI5M44hqGSCGqjfUgOFMU1mye5pcpHRmBO+J2Y7HXSYiCp8D6A9Dag1K03tzSUnw3b62LyuKb9kCku0x1oM6gWzFkE0pv2fCcD4cuQEmqUjiMxKZ9WyZor7Kpx7iWwuGdAj+qKq2XsG0ga5swOG9RatEq9+VUouWacWOt6ZqtfCw50nCSqaU0W+rQvMntm/u66BJnpP5q8V62Oqj4J3EI8CnJRxSvjX2M2zKmnsRS7+s27kX6jhBRtQoDo9GDxoifdXatW4zqHziSWWxferpywxvTVMakB2jUIzHU+GcCL1dV3so7DL5m7oyYJfM8YCPJTMne3ohXmzaZ+F380RGtdhiuMKN+PJABI0R3ZrBa6GXwum+ln9D7gKM0dqcYbTXBMB6+861N16TZ3HxlRJHF4nsfCXRDjwfmUI5XB3Ot+349Tgvpc4O1K2cgDm9xP2MMwT7TeE5uSfFs= 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 6, 2023 at 4:18=E2=80=AFPM Suren Baghdasaryan wrote: > > On Tue, Jun 6, 2023 at 1:15=E2=80=AFPM Vlastimil Babka w= rote: > > > > On 4/13/23 17:36, Peter Xu wrote: > > > On Thu, Apr 13, 2023 at 10:10:44AM +0200, David Hildenbrand wrote: > > >> So instead, we consider the whole address space as a virtual, anon f= ile, > > >> starting at offset 0. The pgoff of a VMA is then simply the offset i= n that > > >> virtual file (easily computed from the start of the VMA), and VMA me= rging is > > >> just the same as for an ordinary file. > > > > > > Interesting point, thanks! > > > > FYI, I've advised a master thesis exploring how to update page->index d= uring > > mremap() to keep things mergeable: > > > > https://dspace.cuni.cz/bitstream/handle/20.500.11956/176288/120426800.p= df > > > > I think the last RFC posting was: > > https://lore.kernel.org/all/20220516125405.1675-1-matenajakub@gmail.com= / > > > > It was really tricky for the general case. Maybe it would be more feasi= ble > > for the limited case Lokesh describes, if we could be sure the pages th= at > > are moved aren't mapped anywhere else. It's great that mremap is being improved for mereabilitly. However, IIUC, it would still cause unnecessary splits and merges in the private anonymous case. Also, mremap works with mmap_sem exclusively held, thereby impacting scalability of concurrent mremap calls. IMHO, Andrea's userfaultfd REMAP patch is a better alternative as it doesn't have these downsides. > > Lokesh asked me to pick up this work and prepare patches for > upstreaming. I'll start working on them after I finish with per-vma > lock support for swap and userfaultd (targeting later this week). > Thanks for all the input folks! Thanks so much, Suren!