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 0E5A0C433F5 for ; Wed, 25 May 2022 07:38:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 94B068D0007; Wed, 25 May 2022 03:38:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D2E88D0002; Wed, 25 May 2022 03:38:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7987E8D0007; Wed, 25 May 2022 03:38:39 -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 680378D0002 for ; Wed, 25 May 2022 03:38:39 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 414BF60E27 for ; Wed, 25 May 2022 07:38:39 +0000 (UTC) X-FDA: 79503463158.02.C80F272 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf09.hostedemail.com (Postfix) with ESMTP id 12EBF14002B for ; Wed, 25 May 2022 07:38:25 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 7DC9F21A18; Wed, 25 May 2022 07:38:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1653464317; 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=6JXUMfpGGhVDZqMhJyol7a8ec7tlpVHE8yXIXgoCFTI=; b=fnyDIvFjkc6ks1LeA5qvR4lALhhKbgNbvXcNUtRuXqwoK0UN1z+P191vCd15NvfMk3KO+v tVIm+/mqgoNDMmEPIpn619Bjv3AnnPxBotUqo19N9XSxbJ3G6TvKWcsH/3uO0TKB97ImPC 3wEZNfM2TcwMYUCIv5/H1g+rNP+OoOI= 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 1DB612C141; Wed, 25 May 2022 07:38:37 +0000 (UTC) Date: Wed, 25 May 2022 09:38:36 +0200 From: Michal Hocko To: CGEL Cc: Balbir Singh , 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 Subject: Re: [PATCH] mm/ksm: introduce ksm_enabled for each processg Message-ID: References: <20220517092701.1662641-1-xu.xin16@zte.com.cn> <6284a2ef.1c69fb81.e53cd.32b2@mx.google.com> <6285e519.1c69fb81.4f3fe.8057@mx.google.com> <628c9cb4.1c69fb81.aec05.30a1@mx.google.com> <628dd307.1c69fb81.91c69.39b2@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <628dd307.1c69fb81.91c69.39b2@mx.google.com> X-Rspam-User: X-Rspamd-Queue-Id: 12EBF14002B X-Stat-Signature: i9pq8ztyhfzuhs5q67fjg5ppjpp15nc6 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=fnyDIvFj; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf09.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam04 X-HE-Tag: 1653464305-607673 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 Wed 25-05-22 06:56:05, CGEL wrote: > On Tue, May 24, 2022 at 11:04:40AM +0200, Michal Hocko wrote: > > On Tue 24-05-22 08:52:02, CGEL wrote: > > > On Thu, May 19, 2022 at 09:39:57AM +0200, Michal Hocko wrote: > > > > On Thu 19-05-22 06:35:03, CGEL wrote: > > > > > On Wed, May 18, 2022 at 02:14:28PM +0200, Michal Hocko wrote: > > > > > > On Wed 18-05-22 07:40:30, CGEL wrote: > > > > > > [...] > > > > > > > 2. process_madvise is still a kind of madvise. processs_madvise from > > > > > > > another process overrides the intention of origin app code ifself that > > > > > > > also calls madvise, which is unrecoverable. For example, if a process "A" > > > > > > > which madvises just one part of VMAs (not all) as MERGEABLE run on the OS > > > > > > > already, meanwhile, if another process which doesn't know the information > > > > > > > of "A" 's MERGEABLE areas, then call process_madvise to advise all VMAs of > > > > > > > "A" as MERGEABLE, the original MERGEABLE information of "A" calling madivse > > > > > > > is erasured permanently. > > > > > > > > > > > > I do not really follow. How is this any different from an external > > > > > > process modifying the process wide policy via the proc or any other > > > > > > interface? > > > > > > > > > > In this patch, you can see that we didn't modify the flag of any VMA of > > > > > the target process, which is different from process_madvise. So it is > > > > > easy to keep the original MERGEABLE information of the target process > > > > > when we turn back to the default state from the state "always". > > > > > > > > This means that /proc//smaps doesn't show the real state, right? > > > > > > Maybe we can add extra information of KSM forcible state in /proc//smaps > > > like THPeligible. > > > > That information is already printed and I do not think that adding > > another flag or whatever would make the situation much more clear. > > > > > Really, Michal, I think it again, 'process_ madvise' is really not good. In > > > addition to some shortcomings I said before, If new vmas of the target process > > > are created after the external process calls process_madvise(), then we have to > > > call `process_madvise()` on them again, over and over again, regularly, just like > > > Oleksandr said [1]. > > > > I can see that this is not the most convenient way but so far I haven't > > really heard any arguments that this would be impossible. > > > > Look, I am not claiming that process_madvise is the only way to achieve > > the goal. I really do not like the proc based interface because it is > > rather adhoc and limited. We have other means to set a process wide > > property and I do not see any strong arguments agaist prctl. > > > > I can agree with you that proc is adhoc and limit. Use prctl extension > is probably better, but the problem is that it can't control external > process directly. Why is that a problem? I have seen this claim in this thread already but never really backed by a usecase where this would be a real problem. Either your tasks want to have their memory KSMed or not. Why do you need to change that during the process runtime? > > But more importantly I haven't really seen any serious analysis whether > > per-process (resp. per MM) property is even a desirable interface. > > Especially in the current form when opting out for certain VMAs is not > > possible. > > I think the reasons of using per-process (resp. per MM) property are as > follows: > > The KSM mandatory attribute is set for the entire mm space rather than > some VMAs. Its system is to allow all eligible VMAs of the entire mm to > participate in KSM. Although marking all VMAs as mergeble can achieve the > same purpose, the concept is different: You are not really answering my question but now that you have brought that up I think that implemenation which would mark all eligible VMAs as VM_MERGE and implicitly set the same for any new VMA would be more reasonable. It wouldn't have the above mentioned problem with MADV_UNMERGEABLE. The thing though is whether there are any usecases which benefit from implicit sharing for all the anonymous memory (including stacks, brk and any random private mmaping backing the heap allocators). > From another perspective, for example, the rule of a company is to hold > a morning meeting at 9:30 a.m., but one day, the local law stipulates > that it is illegal to go to work before 10 o'clock, then this rule of > the company have to be covered and invalid. Here, 'mm->ksm_ enabled' is > analogous to local laws, while the company's rule is analogous to VMA > -> flag. One day, after the local law is repealed, the company's rule > can still be restored. I am sorry but I got lost in your example. Could you talk about specific usecases? -- Michal Hocko SUSE Labs