linux-kernel - Re: [RFC/PATCH 01/17] sched: mix tasks and groups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1207051514.8514.725.camel@twins>
Date:	Tue, 01 Apr 2008 14:05:14 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	vatsa@...ux.vnet.ibm.com
Cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Mike Galbraith <efault@....de>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>
Subject: Re: [RFC/PATCH 01/17] sched: mix tasks and groups

On Tue, 2008-04-01 at 17:42 +0530, Srivatsa Vaddagiri wrote:
> On Sun, Mar 09, 2008 at 06:08:51PM +0100, Peter Zijlstra wrote:
> > This patch allows tasks and groups to exist in the same cfs_rq. With this
> > change the CFS group scheduling follows a 1/(M+N) model from a 1/(1+N)
> > fairness model where M tasks and N groups exist at the cfs_rq level.
> > 
> > [a.p.zijlstra@...llo.nl: rt bits]
> > Signed-off-by: Dhaval Giani <dhaval@...ux.vnet.ibm.com>
> > Signed-off-by: Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
> > Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> > ---
> >  kernel/sched.c      |   54 ++++++++++++++++++++++++++++++++++++++++++++++++++--
> >  kernel/sched_fair.c |   48 +++++++++++++++++++++++++++++++++++++++++++---
> >  kernel/sched_rt.c   |   15 ++++++++------
> >  3 files changed, 106 insertions(+), 11 deletions(-)
> > 
> > Index: linux-2.6-2/kernel/sched.c
> > ===================================================================
> > --- linux-2.6-2.orig/kernel/sched.c
> > +++ linux-2.6-2/kernel/sched.c
> > @@ -273,18 +273,23 @@ struct task_group {
> >  };
> > 
> >  #ifdef CONFIG_FAIR_GROUP_SCHED
> > +
> > +#ifdef CONFIG_USER_SCHED
> >  /* Default task group's sched entity on each cpu */
> >  static DEFINE_PER_CPU(struct sched_entity, init_sched_entity);
> >  /* Default task group's cfs_rq on each cpu */
> >  static DEFINE_PER_CPU(struct cfs_rq, init_cfs_rq) ____cacheline_aligned_in_smp;
> > +#endif
> 
> 
> I am trying to understand the change this brings for semantics of RT-scheduling.
> 
> With this change, /cgroup will be seen as the parent group of all other
> groups (say: /cgroup/A, /cgroup/B etc). Is that correct?
> 
> If so, the check in __rt_schedulable() needs a change as well, which assumes 
> that all task groups form a flat hierarchy.

Yes, I have that on my todo list somewhere. I realized the same thing
earlier today :-)

> For example: lets say that init_task_group (/cgroup in this case) had the
> default rt_bandwidth of 95% (global_rt_runtime()). A child group under it 
> (/cgroup/A) is created. If user tries to assign it a rt-bandwidth of
> 50%, then AFAICS, it will fail with current code, whereas it shouldn't
> (because by giving /cgroup/A 50% bandwidth, we are not really exceeding
> the globally allowed RT bandwidth of 95%, since /cgroup/A is a child of
> /cgroup).


agreed.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/