From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-173.mta0.migadu.com (out-173.mta0.migadu.com [91.218.175.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF41026D4CF for ; Mon, 19 May 2025 13:09:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747660173; cv=none; b=B9KyqUeJ8RyvBTxKTc4snyzO8Pk59NpXyXIngyFKxxB2TVWIN4T86XPGq+aUmTKU0JZJTgY4eCccM9BWWtIN3TS96Lf2NrOYa40Ca8SafPVpxaSg+RAYu2tq8M8nvos5k/0B8JUji/J+Bx0jYwg0y8KFhIXnvTaV8RK5BtZcFos= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747660173; c=relaxed/simple; bh=pSodbc3V4LQg415hXRwcYmpy6/55GRV7K5MO1Cpr8WY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uR8yXnggGph+/L1xD0E3SuInagHlG+7gDFKnmSVHPEtFxeGEZGKgTB3/XdjJJLETqB/JEbDcsKXisvEsztKSoWWmOyFRFji3HaNWc8CduYAEiRZbCbBIXdw7XoQV5W7AyaZz1lekiH93VW95IAnb9ziM+6/EtvdUcsihpylkCJQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=kVt6FymV; arc=none smtp.client-ip=91.218.175.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="kVt6FymV" 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 Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 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!