Re: [RFC 0/1] Introduce new attribute "priority" to control group

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 8, 2021 at 9:51 AM yulei zhang <yulei.kernel@xxxxxxxxx> wrote:
>
> On Mon, Apr 5, 2021 at 1:29 AM Tejun Heo <tj@xxxxxxxxxx> wrote:
> >
> > On Sun, Apr 04, 2021 at 10:51:53PM +0800, yulei.kernel@xxxxxxxxx wrote:
> > > From: Yulei Zhang <yuleixzhang@xxxxxxxxxxx>
> > >
> > > This patch is the init patch of a series which we want to present the idea
> > > of prioritized tasks management. As the cloud computing introduces intricate
> > > configurations to provide customized infrasturctures and friendly user
> > > experiences, in order to maximum utilization of sources and improve the
> > > efficiency of arrangement, we add the new attribute "priority" to control
> > > group, which could be used as graded factor by subssystems to manipulate
> > > the behaviors of processes.
> > >
> > > Base on the order of priority, we could apply different resource configuration
> > > strategies, sometimes it will be more accuracy instead of fine tuning in each
> > > subsystem. And of course to set fundamental rules, for example, high priority
> > > cgroups could seize the resource from cgroups with lower priority all the time.
> > >
> > > The default value of "priority" is set to 0 which means the highest
> > > priority, and the totally levels of priority is defined by
> > > CGROUP_PRIORITY_MAX. Each subsystem could register callback to receive the
> > > priority change notification for their own purposes.
> > >
> > > We would like to send out the corresponding features in the coming weeks,
> > > which are relaying on the priority settings. For example, the prioritized
> > > oom, memory reclaiming and cpu schedule strategy.
> >
> > We've been trying really hard to give each interface semantics which is
> > logical and describable independent of the implementation details. This runs
> > precisely against that.
> >
> > Thanks.
> >
> > --
> > tejun
>
> Thanks for the feedback. I am afraid that I didn't express myself clearly
> about the idea of the priority attribute. We don't want to overwrite
> the semantics
> for each interface in cgroup, just hope to introduce another factor that could
> help us apply the management strategy. For example, In our production
> environment
> K8s has its own priority class to implement the Qos, and it will be
> very helpful
> if control group could provide corresponding priority to assist the
> implementation.

IMHO the 'priority' is a high level concept mainly to define policies
and should not be part of user API. The meaning of priority changes
with each use-case and it can be more than one dimension. For example
I can have two jobs running on a machine. One is a batch and the
second is a latency sensitive job, let's say web server. For oom-kill
use-case, I might prefer to kill the web server as there will be
multiple instances running and the load balancer will redirect the
load. However for memory reclaim, I would prefer to reclaim from batch
as the cost of refaults in the web server is visible to end customers.

Basically we should have mechanisms in the kernel which can be used to
define and enforce high level priorities. I can set memory.low of the
web server to prefer reclaim from batch job. For oom-kill, Android's
lmkd and fb's oomd are the examples of user space oom-killer where
policies are in user space.



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux