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 DEE1EC433FE for ; Fri, 11 Mar 2022 17:46:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 88FEB8D0006; Fri, 11 Mar 2022 12:46:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 81A648D0001; Fri, 11 Mar 2022 12:46:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6932A8D0006; Fri, 11 Mar 2022 12:46:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 5B44F8D0001 for ; Fri, 11 Mar 2022 12:46:05 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 39BBF24FEB for ; Fri, 11 Mar 2022 17:46:05 +0000 (UTC) X-FDA: 79232833890.01.6774C44 Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by imf04.hostedemail.com (Postfix) with ESMTP id B0C3C40026 for ; Fri, 11 Mar 2022 17:46:04 +0000 (UTC) Received: by mail-ej1-f54.google.com with SMTP id gb39so20544068ejc.1 for ; Fri, 11 Mar 2022 09:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=qT0C/6DOfDnLQQ9CEAOqIUTYmrrNFB0d3Kmyk6GQhvw=; b=puPhQxXfJGzYH+7ST3DhcePE8oIDJfjvn0ssWGRr4GYIShmkKrJxfcsQdxOp+9l7Ya 7Ith4Fyu5wlKOAxHpwaPqM3/37xQ/JhNRyJFbFnIJi2YslfOiDy+MywVwF4YqXJ+VCXk iROpqXuI4rSl26OZ8JD3EJiRT9FWa/MzpKPoiubRY6OXHIoqVbFQBEruAo3VdWxusVnq jtj8mSbn9stUuR+Y5D/NQxRQbabfTtOrBl3wNgb4VjMrediwPpXVhiLE9QrGS1683stL +LZw6cHaxMBjqh7aJT1SbrKmFq8wedns2JNjYY7/8qH6bayXhdkeiBgydMRT22dx3iEW r0iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=qT0C/6DOfDnLQQ9CEAOqIUTYmrrNFB0d3Kmyk6GQhvw=; b=TDKvPBbbd5TTKq8wYSgPSNsr/SOlEDw0p5dfaMnmfeN09ByIH1cnF4Ar5Dn0v4pSU5 Qw5MB5DFds+wTqdEExUQ5TtocM2hjVJadl+2b5uzUju7gWIyWOb3/VLlM0Le9iz8g/zi /T8DU5XnJcNHGkighSpKJU2vlRzn6ZfNDEEplHYJS+VjxmTDuQmqfur8OEwu1k0icj2T tkbJ6S8vT/a65typO0jWjRR7mrHzWz58ORkrEgUa7J1vcRmfEROXoUxzaJ563ESVT6bn 4j9T0T9EPo+e0Qzm5I8rke25nBF07YBVJketJ4mAKPxgp7qmoWISmIq0LOW37QJfCUDX PB2g== X-Gm-Message-State: AOAM5316m9Scin2fcaUAVvQBDKQoZg8tyYjx9VdoYTHuK1xk3LTD3U27 HM4chqbtgCUA5xafMbiB5JE= X-Google-Smtp-Source: ABdhPJwy3DVt+jNjoeR35CJN/CVq8mdmJ861/fihAeEdk6RNpPFcZ/1vHGbwOzp8mZtMqTe0SYYmVw== X-Received: by 2002:a17:906:2899:b0:6d6:e479:1fe2 with SMTP id o25-20020a170906289900b006d6e4791fe2mr9671565ejd.394.1647020763499; Fri, 11 Mar 2022 09:46:03 -0800 (PST) Received: from orion.localdomain ([93.99.228.15]) by smtp.gmail.com with ESMTPSA id qb30-20020a1709077e9e00b006d6f8c77695sm3188187ejc.101.2022.03.11.09.46.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Mar 2022 09:46:01 -0800 (PST) Received: by orion.localdomain (Postfix, from userid 1003) id 7F7A1A00BB; Fri, 11 Mar 2022 18:46:03 +0100 (CET) From: =?UTF-8?q?Jakub=20Mat=C4=9Bna?= To: linux-mm@kvack.org Cc: patches@lists.linux.dev, linux-kernel@vger.kernel.org, vbabka@suse.cz, mhocko@kernel.org, mgorman@techsingularity.net, willy@infradead.org, liam.howlett@oracle.com, hughd@google.com, kirill@shutemov.name, riel@surriel.com, rostedt@goodmis.org, peterz@infradead.org, =?UTF-8?q?Jakub=20Mat=C4=9Bna?= Subject: [RFC PATCH v2 0/4] Removing limitations of merging anonymous VMAs Date: Fri, 11 Mar 2022 18:45:58 +0100 Message-Id: <20220311174602.288010-1-matenajakub@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=puPhQxXf; spf=pass (imf04.hostedemail.com: domain of matenajakub@gmail.com designates 209.85.218.54 as permitted sender) smtp.mailfrom=matenajakub@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: B0C3C40026 X-Stat-Signature: q4no5cph39rwn3gdrtw3fqzxoqa5kn58 X-HE-Tag: 1647020764-519132 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: Motivation In the current kernel it is impossible to merge two anonymous VMAs if one of them was moved. That is because VMA's page offset is set according to the virtual address where it was created and in order to merge two VMAs page offsets need to follow up. Another problem when merging two VMA's is their anon_vma. In current kernel these anon_vmas have to be the one and the same. Otherwise merge is again not allowed. There are several places from which vma_merge() is called and therefore several use cases that might profit from this upgrade. These include mmap (that fills a hole between two VMAs), mremap (that moves VMA next to another one or again perfectly fills a hole), mprotect (that modifies protection and allows merging with a neighbor) and brk (that expands VMA so that it is adjacent to a neighbor). Missed merge opportunities increase the number of VMAs of a process and in some cases can cause problems when a max count is reached. Solution Following series of these patches solves the first problem with page offsets by updating them when the VMA is moved to a different virtual address (patch 2). As for the second problem merging of VMAs with different anon_vma is allowed (patch 3). Patch 1 refactors function vma_merge and makes it easier to understand and also allows relatively seamless tracing of successful merges introduced by the patch 4. Limitations For both problems solution works only for VMAs that do not share physical pages with other processes (usually child or parent processes). This is checked by looking at anon_vma of the respective VMA. The reason why it is not possible or at least not easy to accomplish is that each physical page has a pointer to anon_vma and page offset. And when this physical page is shared we cannot simply change these parameters without affecting all of the VMAs mapping this physical page. Good thing is that this case amounts only for about 1-3% of all merges (measured on jemalloc (0%), redis (2.7%) and kcbench (1.2%) tests) that fail to merge in the current kernel. Measuring also shows slight increase in running time, jemalloc (0.3%), redis (1%), kcbench (1%). More extensive data can be viewed at https://home.alabanda.cz/share/results.png This series of patches and documentation of the related code will be part of my master's thesis. This patch series is based on tag v5.17-rc4. This is a second version including minor changes that arose from the first RFC like formatting. Speed and failed merge percentage data are also included. Jakub Matěna (4): mm: refactor of vma_merge() mm: adjust page offset in mremap mm: enable merging of VMAs with different anon_vmas mm: add tracing for VMA merges include/linux/rmap.h | 17 ++- include/trace/events/mmap.h | 83 +++++++++++++++ mm/internal.h | 12 +++ mm/mmap.c | 206 ++++++++++++++++++++++++------------ mm/rmap.c | 77 ++++++++++++++ 5 files changed, 325 insertions(+), 70 deletions(-) -- 2.34.1