linux-kernel - Re: Sched_autogroup and niced processes

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110513100411.GA21022@elte.hu>
Date:	Fri, 13 May 2011 12:04:11 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Mike Galbraith <efault@....de>, Yong Zhang <yong.zhang0@...il.com>,
	Carl-Johan Kjellander <carl-johan@...rna.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Sched_autogroup and niced processes


* Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:

> On Fri, 2011-05-13 at 11:29 +0200, Ingo Molnar wrote:
> > * Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> > 
> > > On Fri, 2011-05-13 at 11:05 +0200, Ingo Molnar wrote:
> > > > Could we somehow automate this:
> > > > 
> > > >   > echo 19 > /proc/'pid of seti@...e'/autogroup
> > > > 
> > > > and split off nice 19 tasks into separate groups and lower the group's 
> > > > priority? 
> > > 
> > > Well I guess you can stack on all kinds of heuristics, do we want to?
> > 
> > Well have you seen my non-heuristic suggestion:
> > 
> >  | Another thing we could do is to lower the priority of a cgroup if it *only* 
> >  | runs reniced tasks. I.e. track the 'maximum priority' of cgroups and 
> >  | propagate that to their weight.
> >  |
> >  | This way renicing within cgroups will be more powerful and people do not have 
> >  | to muck with cgroup details.
> > 
> > A cgroup assuming the highest priority of all tasks it contains is a pretty 
> > natural definition and extension of priorities and also solves this usecase.
> 
> Well, that a heuristic in my book, and it totally destroys the independence 
> of groups from tasks (resulting in O(n) task nice behaviour).
> 
> I really don't see why we should do this, if people don't want what it does, 
> don't use it. If you want something else, you can do all these things from 
> userspace to suit your exact needs.
> 
> We have enough knobs to set things up as you want them, no need to make 
> things more complicated.

Ok, i guess you are right, propagating priorities does break the clean 
hieararchy we have currently.

Still, the other important problem is that we still seem to have a bug, even 
with the cgroup set to low prio seti@...e is sucking up CPU resources ...

Thanks,

	Ingo
--
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/