[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YMjGXlwQEHFwXZ4/@slm.duckdns.org>
Date: Tue, 15 Jun 2021 11:59:25 -0400
From: Tejun Heo <tj@...nel.org>
To: Waiman Long <llong@...hat.com>
Cc: Zefan Li <lizefan.x@...edance.com>,
Johannes Weiner <hannes@...xchg.org>,
Jonathan Corbet <corbet@....net>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Luis Chamberlain <mcgrof@...nel.org>,
Kees Cook <keescook@...omium.org>,
Iurii Zaikin <yzaikin@...gle.com>, x86@...nel.org,
cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 0/4] cgroup/cpuset: Allow cpuset to bound displayed cpu
info
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
pains.
> 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?
>
> https://lore.kernel.org/lkml/20210603212416.25934-1-longman@redhat.com/
>
> I am looking forward for your feedback.
Sorry about the delay. Will take a look later today.
Thanks.
--
tejun
Powered by blists - more mailing lists