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: <AANLkTinp45D+1XM4vc961RRHWK3WV_N7REY2=34X3ir8@mail.gmail.com>
Date:	Tue, 16 Nov 2010 11:35:42 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Vivek Goyal <vgoyal@...hat.com>, david@...g.hm,
	Paul Menage <menage@...gle.com>,
	Lennart Poettering <mzxreary@...inter.de>,
	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 11:13 AM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
>
> Its cpu-controller only, and then only for SCHED_OTHER tasks which are
> proportionally fair.

Well, it's _currently_ CPU controller only. People have already
wondered if we should try to do something similar for IO scheduling
too.

So the thing I think is worth keeping in mind is that the "per-tty
scheduling group" is really just an implementation issue. There is
absolutely no question that it can't be about more than just
scheduling, and that it can't be about more than just tty's also.

And an important thing to keep in mind is that "user interfaces are
bad". The thinner the interface, the better. One of the reasons I
really like autogroup is that it has _no_ interface at all. It's very
much a heuristic, and it has zero user interface (apart from the knob
that turns it on and off, of course). That is a great feature, because
it means that you cannot break the interface. You will never need to
have applications that have special linux-specific hooks in them, or
system daemons who have to touch magical /proc files etc.

One of the problems I found annoying when just testing it using the
plain cgroup interface (before the patch) was the resource management.
You needed root, and they actually made sense requiring root, because
I don't think we _want_ to allow people creating infinite numbers of
cgroups. Vivek's "trivial patch" (shell script) is a major DoS thing,
for example. Letting normal users create cgroups willy-nilly is not a
good idea (and as Vivek already found out, his trivial script leaks
cgroups in a pretty fundamental way).

The tty approach is somewhat self-limiting in that it requires you to
get the tty to get an autogroup. But also, because it's very much a
heuristic and doesn't have any user-visible interfaces, from a kernel
perspective it's wonderful. There are no "semantics" to break. If it
turns out that there is some way to create excessive cgroups, we can
introduce per-user limits etc to say "the heuristic works up to X
cgroups and then you'll just get your own user group". And nobody
would ever notice.

So doing things automatically and without any user interface is about
_more_ than just convenience. If it can be done that way, it is
fundamentally better way to do things. Because it hides the
implementation details, and leaves us open to do totally different
things in the end.

For example, 'cgroups' itself is pretty heavy-weight, and is really
quite smart. Those things nest, etc etc. But with the "it's just a
heuristic", maybe somebody ends up doing a "simplified non-nesting
grouping thing", and if you don't want the whole cgroup thing (I have
always answered no to CONFIG_CGROUPS myself, for example), you could
still do the autogrouping. But you could _not_ cleanly do the
/proc/sys/cgroup/user scripting, because your implementation is no
longer based on the whole cgroups thing.

Now, will any of this ever happen? I dunno. I doubt it will matter.
But it's an example of why I think it's such a great approach, and why
"it just works" is such an important feature.

                       Linus

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