linux-kernel - Re: [RFC/RFT PATCH v3] sched: automated per tty task 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101116192206.GG13092@redhat.com>
Date:	Tue, 16 Nov 2010 14:22:06 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	david@...g.hm, Paul Menage <menage@...gle.com>,
	Lennart Poettering <mzxreary@...inter.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dhaval Giani <dhaval.giani@...il.com>,
	Mike Galbraith <efault@....de>,
	Oleg Nesterov <oleg@...hat.com>,
	Markus Trippelsdorf <markus@...ppelsdorf.de>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>
Subject: Re: [RFC/RFT PATCH v3] sched: automated per tty task groups

On Tue, Nov 16, 2010 at 08:13:20PM +0100, Peter Zijlstra wrote:
> On Tue, 2010-11-16 at 14:09 -0500, Vivek Goyal wrote:
> 
> > I think this might create some issues with controllers which support some
> > kind of upper limit on resource usage. These hidden group can practically
> > consume any amount of resource and because use space tools can't see these,
> > they will not be able to place a limit or control it.
> > 
> > If it is done from user space and cgroups are visible, then user can 
> > atleast monitor the resource usage and do something about it.
> 
> Its cpu-controller only, and then only for SCHED_OTHER tasks which are
> proportionally fair.

In this thread there are already mentions of extending it to block
controller also which now supports the upper limit.

Secondly I am assuming at some point of time, cpu controller will also
support throttling (including SCHED_OTHER class).

So as it is not a problem but the moment we start extending this logic
to other controllers supporting upper limits it does pose the question
that how do we handle it.

Even if we automatically create groups inside the kernel (because for all the
reasons that why user space can't do it), it probably should create cgroups
also so that these are visible to user space and not hidden.

Thanks
Vivek
--
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/