From: Michal Hocko <mhocko@suse.com>
To: Zhongkun He <hezhongkun.hzk@bytedance.com>
Cc: corbet@lwn.net, akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
wuyun.abel@bytedance.com
Subject: Re: [External] Re: [RFC] proc: Add a new isolated /proc/pid/mempolicy type.
Date: Mon, 26 Sep 2022 16:08:43 +0200 [thread overview]
Message-ID: <YzGya2Q3iuWS2WdM@dhcp22.suse.cz> (raw)
In-Reply-To: <24b20953-eca9-eef7-8e60-301080a17d2d@bytedance.com>
On Mon 26-09-22 20:53:19, Zhongkun He wrote:
> > [Cc linux-api - please do so for any patches making/updating
> > kernel<->user interfaces]
> >
> >
> > On Mon 26-09-22 17:10:33, hezhongkun wrote:
> > > From: Zhongkun He <hezhongkun.hzk@bytedance.com>
> > >
> > > /proc/pid/mempolicy can be used to check and adjust the userspace task's
> > > mempolicy dynamically.In many case, the application and the control plane
> > > are two separate systems. When the application is created, it doesn't know
> > > how to use memory, and it doesn't care. The control plane will decide the
> > > memory usage policy based on different reasons.In that case, we can
> > > dynamically adjust the mempolicy using /proc/pid/mempolicy interface.
> >
> > Is there any reason to make it procfs interface rather than pidfd one?
>
> Hi michal, thanks for your reply.
>
> I just think that it is easy to display and adjust the mempolicy using
> procfs. But it may not be suitable, I will send a pidfd_set_mempolicy patch
> later.
proc interface has many usability issues. That is why pidfd has been
introduced. So I would rather go with the pidfd interface than repeating
old proc API mistakes.
> Btw.in order to add per-thread-group mempolicy, is it possible to add
> mempolicy in mm_struct?
I dunno. This would make the mempolicy interface even more confusing.
Per mm behavior makes a lot of sense but we already do have per-thread
semantic so I would stick to it rather than introducing a new semantic.
Why is this really important?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2022-09-26 15:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-26 9:10 [RFC] proc: Add a new isolated /proc/pid/mempolicy type hezhongkun
2022-09-26 9:56 ` Michal Hocko
2022-09-26 12:53 ` [External] " Zhongkun He
2022-09-26 14:08 ` Michal Hocko [this message]
2022-09-27 3:20 ` Abel Wu
2022-09-27 10:49 ` Michal Hocko
2022-09-27 13:07 ` [External] " Abel Wu
2022-09-27 13:58 ` Michal Hocko
2022-09-28 3:09 ` Abel Wu
2022-09-30 8:54 ` Michal Hocko
2022-09-28 23:39 ` [External] " Randy Dunlap
2022-09-28 11:14 ` kernel test robot
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=YzGya2Q3iuWS2WdM@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=hezhongkun.hzk@bytedance.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=wuyun.abel@bytedance.com \
/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.