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 F3644C433EF for ; Fri, 20 May 2022 12:23:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F49C6B0071; Fri, 20 May 2022 08:23:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4AF046B0072; Fri, 20 May 2022 08:23:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 36BBA6B0073; Fri, 20 May 2022 08:23:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 244756B0071 for ; Fri, 20 May 2022 08:23:02 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E87E62185D for ; Fri, 20 May 2022 12:23:01 +0000 (UTC) X-FDA: 79486035762.07.A601227 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf20.hostedemail.com (Postfix) with ESMTP id 419F91C0005 for ; Fri, 20 May 2022 12:22:48 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id B5BF621BD8; Fri, 20 May 2022 12:22:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1653049379; h=from:from:reply-to: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; bh=C55mA7Gcdj6mV5Wh6tOYntZbioSd1fH8dLwGmuS/9aw=; b=h6D0ikPKhhJQ2bvLnSJWEQNqQ/s1NiEdAOK4vk3m/DR9/sNKkX/hZ2xRsaNmAhib7rypXR 7OzYKcPQG55MzIw2/LniYnQNChudwQ7wpP6zDuAkvlVWSMlGaMcxwmcdS+usHfrBjeCCty x26oNmmTKBvysdApyUmNqwlmO0GeUy8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1653049379; h=from:from:reply-to: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; bh=C55mA7Gcdj6mV5Wh6tOYntZbioSd1fH8dLwGmuS/9aw=; b=EM51IkLUUliO6PAFaRMUPUHvBxvMqTA4Aag1UCKGtUvCjCmVuQAjiGqg6Dc7yxrn/mkvUz ziJtrOh8Hc/uFjBg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 8125F13AF4; Fri, 20 May 2022 12:22:59 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id DMqzHiOIh2JpRAAAMHmgww (envelope-from ); Fri, 20 May 2022 12:22:59 +0000 Message-ID: <408b79d9-e96a-b961-1565-93bf11e54909@suse.cz> Date: Fri, 20 May 2022 14:22:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: "Kirill A. Shutemov" , =?UTF-8?Q?Jakub_Mat=c4=9bna?= Cc: linux-mm@kvack.org, patches@lists.linux.dev, linux-kernel@vger.kernel.org, mhocko@kernel.org, mgorman@techsingularity.net, willy@infradead.org, liam.howlett@oracle.com, hughd@google.com, riel@surriel.com, rostedt@goodmis.org, peterz@infradead.org, david@redhat.com References: <20220516125405.1675-1-matenajakub@gmail.com> <20220517164403.nabrtbkezex7uof4@box.shutemov.name> From: Vlastimil Babka Subject: Re: [RFC PATCH v3 0/6] Removing limitations of merging anonymous VMAs In-Reply-To: <20220517164403.nabrtbkezex7uof4@box.shutemov.name> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 419F91C0005 X-Stat-Signature: 3acota9zdo3r6zzroxywrj6ffw36xpgr X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=h6D0ikPK; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=EM51IkLU; spf=pass (imf20.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none X-HE-Tag: 1653049368-731673 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 5/17/22 18:44, Kirill A. Shutemov wrote: > On Mon, May 16, 2022 at 02:53:59PM +0200, Jakub Matěna wrote: >> This is a series of patches that try to improve merge success rate when >> VMAs are being moved, resized or otherwise modified. >> >> 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 faulted 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. > > Hm. You are talking about missed opportunities, but do you know any > workload that would measurably benefit from the change? We do know about a workload that originally inspired this investigation of feasibility, but it's proprietary and will take a while to evaluate the benefits there. We did hope that a public RFC could lead to discovering others that also have a workload that would benefit, and might currently use some userspace workarounds due to the existing limitations. > The changes are not trivial. And rmap code is complex enough as it is. True, it was one of the goals, to see how complex exactly it would be. And an opportunity to better document related parts of mm as part of the master thesis :) > I expect common cases to get slower due to additional checks that do not > result in more merges. Stats so far have shown that merges that this enables did happen, only a few percent cases didn't. Of course for many workloads the extra merges will not bring much benefit. One possibility is to introduce an opt-in mode (prctl or madvise?) for workloads that know they would benefit. > I donno, the effort looks dubious to me as of now. At least patches 1+2 could be considered immediately, as they don't bring extra complexity. A related issue which was brought to our attention is that current mremap() implementation doesn't work on a range that spans multiple vma's. The multiple vma's may be result of the current insufficient merging, or otherwise. And it's tedious for userspace to discover the boundaries from /proc/pid/maps to guide a mremap() vma by vma. More sucessful merging would thus help, but it should be also possible to improve the mremap() implementation, which shouldn't be as complex...