archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <>
To: Waiman Long <>
Cc: Zefan Li <>,
	Johannes Weiner <>,
	Jonathan Corbet <>,
	Thomas Gleixner <>,
	Ingo Molnar <>, Borislav Petkov <>,
	"H. Peter Anvin" <>,
	Greg Kroah-Hartman <>,
	"Rafael J. Wysocki" <>,
	Luis Chamberlain <>,
	Kees Cook <>,
	Iurii Zaikin <>,,,,,
Subject: Re: [PATCH 0/4] cgroup/cpuset: Allow cpuset to bound displayed cpu info
Date: Tue, 15 Jun 2021 11:59:25 -0400	[thread overview]
Message-ID: <YMjGXlwQEHFwXZ4/> (raw)
In-Reply-To: <>

Hello, Waiman.

On Mon, Jun 14, 2021 at 10:53:53PM -0400, Waiman Long wrote:
> Thanks for your comment. I understand your point making change via cgroup
> interface files. However, this is not what the customers are asking for.

It's not like we can always follow what specific customers request. If there
are actual use-cases that can't be achieved with the existing interfaces and
features, we can look into how to provide those but making interface
decisions based on specific customer requests tends to lead to long term

> They are using tools that look at /proc/cpuinfo and the sysfs files. It is a
> much bigger effort to make all those tools look at a new cgroup file
> interface instead. It can be more efficiently done at the kernel level.

Short term, sure, it sure is more painful to adapt, but I don't think longer
term solution lies in the kernel trying to masquerage existing sytsem-wide
information interfaces. e.g. cpuset is one thing but what are we gonna do
about weight control or work-conserving memory controls? Pro-rate cpu count
and available memory?

> Anyway, I am OK if the consensus is that it is not a kernel problem and have
> to be handled in userspace.

I'd be happy to provide more information from kernel side as necessary but
the approach taken here doesn't seem generic or scalable at all.

> BTW, do you have any comment on another cpuset patch that I sent a week
> earlier?
> I am looking forward for your feedback.

Sorry about the delay. Will take a look later today.



  reply	other threads:[~2021-06-15 16:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
2021-06-14 15:52   ` [PATCH 4/4] driver core: Allow showing cpu as offline if not valid in cpuset context Greg KH
2021-06-14 16:32     ` Waiman Long
2021-06-14 17:00       ` Greg KH
2021-06-14 20:43 ` [PATCH 0/4] cgroup/cpuset: Allow cpuset to bound displayed cpu info Tejun Heo
2021-06-15  2:53   ` Waiman Long
2021-06-15 15:59     ` Tejun Heo [this message]
2021-06-15  9:14   ` Christian Brauner

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:

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

  git send-email \
    --in-reply-to=YMjGXlwQEHFwXZ4/ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).