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 1753CC433F5 for ; Wed, 25 May 2022 06:56:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 45ACC8D0003; Wed, 25 May 2022 02:56:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 405718D0001; Wed, 25 May 2022 02:56:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F6958D0003; Wed, 25 May 2022 02:56:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1D8E78D0001 for ; Wed, 25 May 2022 02:56:10 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id DBFE860DA3 for ; Wed, 25 May 2022 06:56:09 +0000 (UTC) X-FDA: 79503356058.23.BEA9136 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf19.hostedemail.com (Postfix) with ESMTP id BA24E1A0005 for ; Wed, 25 May 2022 06:55:56 +0000 (UTC) Received: by mail-pj1-f51.google.com with SMTP id n10so18866509pjh.5 for ; Tue, 24 May 2022 23:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:from:to:cc:subject:references:mime-version :content-disposition:in-reply-to; bh=MnCjWu89qxOeZvUeYKgLrL67m/1ovdJFmFA+h6t4yJg=; b=lN4TpjftivnR9SEc4SzLFhhQ4OTw+aIVbrMYJx1nI8YZmfCoQPb+zuEbJgj4oFXvYv bm4QsuaiMsoWLUEOn3wAxli9TvRd/cTU9xK2gtFKmPu92Sp/d0nraVzzqB2UzJQcQn16 3jcU6GNGkaQKJ0IpdUWmy+SpM8j1OC86DVlSeJFdozBCfduYRy1jQ7im/n7S1+oQZIjZ Lu5MwJTqEL8+vne855DqNvuo0PUQG+5ZAeZ/dbg3YOIN7NY7ewIZ30SzJ5Ru3gJE0+ih fCA5x9uzEN73PvKEKUZciURPhHcZkzZVO6RVFnFLxOWYcupwNByxlUDsfgUIxq4hj+XW HFTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:from:to:cc:subject:references :mime-version:content-disposition:in-reply-to; bh=MnCjWu89qxOeZvUeYKgLrL67m/1ovdJFmFA+h6t4yJg=; b=LdpmPmL1z3Pmgr9ckyc0F6Jkv9g6eDEkh6GKPFgtY5DlpbfuYxnUL2CaokiHfAtj4Y LCXznbL1nIaU1qKUCifNJFSyBrM7KjAu7dfQ1Omhrg5AfWkqrj+XGDT2ONpYpjsN2dMI 2k1LaSjN1NM4OEwuzQ0NEnUJ/hnGEVL38nqfhAgrwPtdmhMAPtU4PD2fzhSoI0EME5IG jkJMjAwCHYoPuLDRzXFPwuc/N++ZFob4ShxQW8Vm6EPHtvOu22tr5TYFbX4ynahWIufV dpuClfJXQ5B7C3X7YQbS5FjjqVOX2fK2qbwcU57O1cC2wX5L+WvBKRJPFpLEZ0s/J0Pi pXbQ== X-Gm-Message-State: AOAM532ZugU0b5aKPmIqDSKm8BObGdHUigTRXL8bwnnXNXanBlw6n/vk 5KBK2CUAvokUGsVOM+ictCM= X-Google-Smtp-Source: ABdhPJxDQxQxstQoFUs4gh4zJcPHkok1CrbJULV/4CMw409OGkWYE3cii1zC+jFJZUGo1OJZtRhIAg== X-Received: by 2002:a17:90b:3b8e:b0:1df:fd93:b37b with SMTP id pc14-20020a17090b3b8e00b001dffd93b37bmr8634064pjb.147.1653461768398; Tue, 24 May 2022 23:56:08 -0700 (PDT) Received: from localhost ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id x7-20020a1709027c0700b0015e8d4eb29esm8313290pll.232.2022.05.24.23.56.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 May 2022 23:56:07 -0700 (PDT) Message-ID: <628dd307.1c69fb81.91c69.39b2@mx.google.com> X-Google-Original-Message-ID: <20220525065605.GA53111@cgel.zte@gmail.com> Date: Wed, 25 May 2022 06:56:05 +0000 From: CGEL To: Michal Hocko 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 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: BA24E1A0005 X-Stat-Signature: 193tw34pzrafb3sa96upm78i1zckkh4y Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=lN4Tpjft; spf=pass (imf19.hostedemail.com: domain of cgel.zte@gmail.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=cgel.zte@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam03 X-HE-Tag: 1653461756-728156 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 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. > 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: >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. > > > -- > Michal Hocko > SUSE Labs