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
| ||
|
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/
Powered by blists - more mailing lists