From: Zhongkun He <hezhongkun.hzk@bytedance.com>
To: Michal Hocko <mhocko@suse.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 20:53:19 +0800 [thread overview]
Message-ID: <24b20953-eca9-eef7-8e60-301080a17d2d@bytedance.com> (raw)
In-Reply-To: <YzF3aaLvEvFhTQa3@dhcp22.suse.cz>
> [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.
Btw.in order to add per-thread-group mempolicy, is it possible to add
mempolicy in mm_struct?
next prev parent reply other threads:[~2022-09-26 14:35 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 ` Zhongkun He [this message]
2022-09-26 14:08 ` [External] " Michal Hocko
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=24b20953-eca9-eef7-8e60-301080a17d2d@bytedance.com \
--to=hezhongkun.hzk@bytedance.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--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.