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 2C64FC2D0CD for ; Mon, 19 May 2025 13:09:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E29CC6B00CB; Mon, 19 May 2025 09:09:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE68B6B00D3; Mon, 19 May 2025 09:09:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C53CA6B00D4; Mon, 19 May 2025 09:09:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A5CE46B00CB for ; Mon, 19 May 2025 09:09:19 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D2501C04DE for ; Mon, 19 May 2025 13:09:23 +0000 (UTC) X-FDA: 83459688606.21.7BCE2A7 Received: from out-170.mta0.migadu.com (out-170.mta0.migadu.com [91.218.175.170]) by imf27.hostedemail.com (Postfix) with ESMTP id D5F1A40014 for ; Mon, 19 May 2025 13:09:21 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=kVt6FymV; spf=pass (imf27.hostedemail.com: domain of chengming.zhou@linux.dev designates 91.218.175.170 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747660162; 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=rdkhBGRvUC+ooGHKKuYF8USNZA83y6OB9dcv1mAc5tE=; b=8P8OFuMtBJ3M2ahbAjZdG7fbbI3eConIAnhq2QkQnR7uBzOWRLj+ZhYagSMrcbAIJ8cGRT SsnSX/0hiTNJmybhiKoPShLcAgJiuKi087chldlnlyS5708bvmyM46ZovPBBiXg7GDXifC AupSPiX3LQP/zuMT9S5nMe+nX4p+unE= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=kVt6FymV; spf=pass (imf27.hostedemail.com: domain of chengming.zhou@linux.dev designates 91.218.175.170 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747660162; a=rsa-sha256; cv=none; b=neLS9cnkhmrrxkHSR7XzcvLFKABG2yYLUBioW83NQwW/bx9IIds+i1cDc+DPHcmg39kynr zOyYLXQUcECUb3YDQ/lSfcqmR859e2nHM4KVKMaxte4wYROadD6StyAtqR7XuU7+/2UcaM w4k/uTUgFlyEL100CoSowjzAGIT42TQ= Message-ID: <4be335ac-8b6e-4714-bce3-f62495dbee8d@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1747660158; h=from:from: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; bh=rdkhBGRvUC+ooGHKKuYF8USNZA83y6OB9dcv1mAc5tE=; b=kVt6FymVrPtkk86vbo79J/uBt+0rC5tjRuQe08F5KwEFzrpo8lRPNbd3FC7quxOK+Us5Cn yyT69rVVn5Sfo8ovWAv+sCcoKZgTZoLfWWcX+/fOGVjNu30rz7Rw3H6szxU62MfPhdRvcs c3Dg+0hNCPkpkTRjbiU1EFlwvdmKJBU= Date: Mon, 19 May 2025 21:08:57 +0800 MIME-Version: 1.0 Subject: Re: [PATCH 3/4] mm: prevent KSM from completely breaking VMA merging To: Lorenzo Stoakes , Andrew Morton Cc: Alexander Viro , Christian Brauner , Jan Kara , "Liam R . Howlett" , Vlastimil Babka , Jann Horn , Pedro Falcato , David Hildenbrand , Xu Xin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org References: <418d3edbec3a718a7023f1beed5478f5952fc3df.1747431920.git.lorenzo.stoakes@oracle.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chengming Zhou In-Reply-To: <418d3edbec3a718a7023f1beed5478f5952fc3df.1747431920.git.lorenzo.stoakes@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: D5F1A40014 X-Rspamd-Server: rspam09 X-Stat-Signature: krecn6w9zd7zoz5q1incu7uuhekewjd5 X-HE-Tag: 1747660161-656606 X-HE-Meta: U2FsdGVkX18A9YLFHgh16tnJa6NH+C7JSAoqRNLsS145IVjGqwSLJR9q1dBAnlz9GrshEcnFsPtafTVSH0KGepkKRz5YUGCd/YFKY8akE3+xoyj8/eHEgojA0V+s4P5K+RFs/xxLGBCVcjA6od38/ygEejjqhWJVaCbPT0CLs1cMHrUc/suadt0jbPEqPN3fddVm8ouJT9aiXlDyqc7v5Fh5dbKJEFsRlMSQTWYlEwdH6rgbuJVLQIXRdeEFmNEEdxFwvOW8py0bn1saK+NqC8J2CwlArsS0bWrQZ6l4bNP5YhS4n65gq+4NBwBOEeztiZVtGWda8GfhGn5UhaO/lMXdhBFdchXYjc5cde23HhdIJHeE2fIVs1G3yIDn7fWOfqVR72VoeIPKpelnUs+8cgAabxg4wxyC5KC7RFb5BpamRXtr0pm+5awfBdi/66gXK3gPcEjRcc2AU/2TFlJ0pTxJSWU6CvqhIJVhklbVtrbrX5HEEq7tqufOiaq1PetJz0EWjlS12Y6U9/Gy+2kloPlJ5uZQwaeTxzXuER8vCPtZ3nQIHEyRFFq3HP3tqvMhuU9xQZdwPRafZaohdiNfqcumNEkALC526i891PX3z+PyCVmC7s9I8TiXxFa8g289laKLsPj1gCxD8TxPeHoSp+G0QSbT8P0HBy6pXIAcAsNEhi8YYNrvh2WOyp3LlNiIvqejWgI3u0HorcKqIM4pqX5qn7F+lok3cp856eCpZbUeOW1LYNhblbsxSiHBNdnyxLPyws+pyXtIMWXzjMeZn/OyK/a0pFILpo/xvKcd6uxPyo44yayLoqXBoiDKXSFny+hJc+VDA2WNbLHubb5P5sXWFT8qX03alyxPiR7RgXsIFh3tHDWqINTWpv2jkmNFVEiXicThb8yBPuXw0FIz95WNWwEXmEl3fISkqB3CnwFeXc6HocPh7hew/EvzmaGkATbjZjqVrue5ca6iBAH 7GCiVKKD 1r58mq+Jd52HETET7Z2y9eyk/yVsxzgJULH8OuTt40w9HT4specOAw0st+OWb/6E5ppAml91IF6/ier+ZumnT2cvEdxhBaXgUGkqBSxVlLeGmUPr4wCTRsegoybEOKEESDolMs2XKHRS+0p6mx8Q/6MtW2YmC8cHjyCjBeX9X9PQzjFQrnmO6GItinkB0odcAX+G67iI6g97nu9FLWhjL3lWK6Uxqyhg0Rx1N 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: List-Subscribe: List-Unsubscribe: On 2025/5/19 16:51, Lorenzo Stoakes wrote: > If a user wishes to enable KSM mergeability for an entire process and all > fork/exec'd processes that come after it, they use the prctl() > PR_SET_MEMORY_MERGE operation. > > This defaults all newly mapped VMAs to have the VM_MERGEABLE VMA flag set > (in order to indicate they are KSM mergeable), as well as setting this flag > for all existing VMAs. > > However it also entirely and completely breaks VMA merging for the process > and all forked (and fork/exec'd) processes. > > This is because when a new mapping is proposed, the flags specified will > never have VM_MERGEABLE set. However all adjacent VMAs will already have > VM_MERGEABLE set, rendering VMAs unmergeable by default. Great catch! I'm wondering how about fixing the vma_merge_new_range() to make it mergeable in this case? > > To work around this, we try to set the VM_MERGEABLE flag prior to > attempting a merge. In the case of brk() this can always be done. > > However on mmap() things are more complicated - while KSM is not supported > for file-backed mappings, it is supported for MAP_PRIVATE file-backed > mappings. So we don't need to set VM_MERGEABLE flag so early, given these corner cases that you described below need to consider. > > And these mappings may have deprecated .mmap() callbacks specified which > could, in theory, adjust flags and thus KSM merge eligiblity. > > So we check to determine whether this at all possible. If not, we set > VM_MERGEABLE prior to the merge attempt on mmap(), otherwise we retain the > previous behaviour. > > When .mmap_prepare() is more widely used, we can remove this precaution. Sounds good too. > > While this doesn't quite cover all cases, it covers a great many (all > anonymous memory, for instance), meaning we should already see a > significant improvement in VMA mergeability. > Agree, it's a very good improvement. Thanks!