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 705C8C433F5 for ; Thu, 19 May 2022 08:24:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3A656B0072; Thu, 19 May 2022 04:24:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC33E6B0073; Thu, 19 May 2022 04:24:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D636E6B0074; Thu, 19 May 2022 04:24:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C16316B0072 for ; Thu, 19 May 2022 04:24:10 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8ED8532238 for ; Thu, 19 May 2022 08:24:10 +0000 (UTC) X-FDA: 79481805060.29.CCBF657 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf13.hostedemail.com (Postfix) with ESMTP id E2516200CD for ; Thu, 19 May 2022 08:23:46 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id D12571F86B; Thu, 19 May 2022 08:24:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1652948648; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rwOhrJSnnXYoizy86SeAUsXvstx5Qk5Sxc5L+MZBqyo=; b=j1hPdPE4GhTJhJXK5vft++K8S2O3MW6b5IsLzl2daI0uZUWn59BeqXofVnLyF0BFhi1KwH wGpS8EufX9bKXt9AKCvcbYvBFE5Lh0Pi6arigelrUHexT0SCvFN5d+iEubG+GdikL7MSjR LRGj4XLhExkDFG/e7AH53Mjsj/1JxTA= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 3FBFA2C180; Thu, 19 May 2022 08:24:08 +0000 (UTC) Date: Thu, 19 May 2022 10:24:06 +0200 From: Michal Hocko To: CGEL Cc: akpm@linux-foundation.org, ammarfaizi2@gnuweeb.org, oleksandr@natalenko.name, willy@infradead.org, linux-mm@kvack.org, corbet@lwn.net, linux-kernel@vger.kernel.org, xu xin , Yang Yang , Ran Xiaokai , wangyong , Yunkai Zhang , Jiang Xuexin , Hugh Dickins , linux-api@vger.kernel.org Subject: Re: [PATCH] mm/ksm: introduce ksm_enabled for each process Message-ID: References: <20220517092701.1662641-1-xu.xin16@zte.com.cn> <62845e2b.1c69fb81.cbf4a.1200@mx.google.com> <6285e264.1c69fb81.3f416.71a8@mx.google.com> <6285f983.1c69fb81.b0a8b.837f@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6285f983.1c69fb81.b0a8b.837f@mx.google.com> X-Rspamd-Queue-Id: E2516200CD X-Stat-Signature: dxru1farny1tse4gec3i1h3ybiga4srs X-Rspam-User: Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=j1hPdPE4; spf=pass (imf13.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam09 X-HE-Tag: 1652948626-756994 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 Thu 19-05-22 08:02:10, CGEL wrote: > On Thu, May 19, 2022 at 09:35:30AM +0200, Michal Hocko wrote: > > On Thu 19-05-22 06:23:30, CGEL wrote: > > > On Wed, May 18, 2022 at 02:12:26PM +0200, Michal Hocko wrote: > > > > On Wed 18-05-22 02:47:06, CGEL wrote: > > > > > On Tue, May 17, 2022 at 04:04:38PM +0200, Michal Hocko wrote: > > > > > > [CCing Hugh and linux-api] > > > > > > > > > > > > On Tue 17-05-22 09:27:01, cgel.zte@gmail.com wrote: > > > > > > per mm but the actual implementation currently relies on the per-vma > > > > > > flags. That means that one can explicitly disallow merging by madvise > > > > > > for a range. Is it wise to override that by a per-process knob? I mean > > > > > > there might be a very good reason why a particular memory ranges should > > > > > > never be merged but a per-process knob could easily ignore that hint > > > > > > from the application. Or am I just confuse? > > > > > For now, there is no any hints for letting KSM never merge some memory > > > > > ranges. > > > > > > > > I am not sure I understand. Could you be more specific? > > > > > > Not like THP, KSM doesn't have anything like VM_NOHUGEPAGE, so apps > > > cann't explicitly disallow merging by madvise. If it is really necessary for > > > a particular meory ranges of a process to be never merged, we have to submit > > > one more patch to achieve that. > > > > What about MADV_UNMERGEABLE? > > MADV_UNMERGEABLE and MADV_MERGEABLE usually appear in pairs, MADV_UNMERGEABLE cannot > appear alone. That might be the case currently because KSM is an opt-in feature that has to be explicitly enabled. The existing interface only allows to enable it by MADV_MERGEABLE but now you are proposing an extension when there would be other way to achieve the same (with a wider scope but that is not really all that important). MADV_UNMERGEABLE has a well defined behavior even on VMAs which are not marked for merging. Let's say that somebody would like to use a process wide setup except for few special mappings because merging is not really desirable for whatever reason. How do you achieve that? > I mean MADV_UNMERGEABLE is used to unmerges whatever it merged in the > specifed range, not to disallow merging. I disagree. It clearly drops the mergeable flag so it effectivelly disallow merging. -- Michal Hocko SUSE Labs