All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: CGEL <cgel.zte@gmail.com>
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 <xu.xin16@zte.com.cn>, Yang Yang <yang.yang29@zte.com.cn>,
	Ran Xiaokai <ran.xiaokai@zte.com.cn>,
	wangyong <wang.yong12@zte.com.cn>,
	Yunkai Zhang <zhang.yunkai@zte.com.cn>,
	Jiang Xuexin <jiang.xuexin@zte.com.cn>,
	Hugh Dickins <hughd@google.com>,
	linux-api@vger.kernel.org
Subject: Re: [PATCH] mm/ksm: introduce ksm_enabled for each process
Date: Thu, 19 May 2022 10:24:06 +0200	[thread overview]
Message-ID: <YoX+ps7fYFMqjQDq@dhcp22.suse.cz> (raw)
In-Reply-To: <6285f983.1c69fb81.b0a8b.837f@mx.google.com>

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

  reply	other threads:[~2022-05-19  8:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-17  9:27 [PATCH] mm/ksm: introduce ksm_enabled for each process cgel.zte
2022-05-17 14:04 ` Michal Hocko
2022-05-18  2:47   ` CGEL
2022-05-18 12:12     ` Michal Hocko
2022-05-19  6:23       ` CGEL
2022-05-19  7:35         ` Michal Hocko
2022-05-19  8:02           ` CGEL
2022-05-19  8:24             ` Michal Hocko [this message]
2022-05-18  6:58 ` Balbir Singh
2022-05-18  7:40   ` [PATCH] mm/ksm: introduce ksm_enabled for each processg CGEL
2022-05-18 12:14     ` Michal Hocko
2022-05-19  6:35       ` CGEL
2022-05-19  7:39         ` Michal Hocko
2022-05-24  8:52           ` CGEL
2022-05-24  9:04             ` Michal Hocko
2022-05-25  6:56               ` CGEL
2022-05-25  7:38                 ` Michal Hocko
2022-05-18 14:31 ` [PATCH] mm/ksm: introduce ksm_enabled for each process Jann Horn
2022-05-19  3:39   ` CGEL

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YoX+ps7fYFMqjQDq@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=ammarfaizi2@gnuweeb.org \
    --cc=cgel.zte@gmail.com \
    --cc=corbet@lwn.net \
    --cc=hughd@google.com \
    --cc=jiang.xuexin@zte.com.cn \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=oleksandr@natalenko.name \
    --cc=ran.xiaokai@zte.com.cn \
    --cc=wang.yong12@zte.com.cn \
    --cc=willy@infradead.org \
    --cc=xu.xin16@zte.com.cn \
    --cc=yang.yang29@zte.com.cn \
    --cc=zhang.yunkai@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.