linux-kernel - Re: [RFC/RFT PATCH v3] sched: automated per tty task groups ... ps jaxk sid ... You are using the wrong number.

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: <Pine.LNX.4.61.1011201009530.8468@mayday.local>
Date:	Sat, 20 Nov 2010 13:11:41 +0000 (GMT)
From:	Robert de Bath <robert$@...ath.co.uk>
To:	Linus Walleij <linus.ml.walleij@...il.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC/RFT PATCH v3] sched: automated per tty task groups ... ps
 jaxk sid ... You are using the wrong number.

On Sat, 20 Nov 2010, Linus Walleij wrote:

> 2010/11/19 Robert de Bath <robert$@...ath.co.uk>:
>
>> Using the SID solves the "all GUI programs are in the same group" problem
>> but still keeps "make -j99" in one group and different [a-z]terms in
>> different groups. What's more setsid(1) and setsid(2) make userspace
>> control really easy.
>
> I grouped all the processes on my system but a few into per-session
> control groups by a quick python hack into CGFreak. It looks very
> funny atleast, I never spawned so many groups before:
> http://www.df.lth.se/~triad/sidgroups/

Sure looks like I would expect; after all 99% of the processes a system
has running are completely idle.  With a normal cgroups setup you're
only interested in the processes that are actually being a problem,
the ones that you know want to eat CPUs, like "make -j99+gcc", like
"apache+php". But here we're not using those extra assumptions, so you
have to cut up the process list at every reasonable boundry.

If you're in userspace (eg your python script) it might be reasonable
to have an idleness test and arrange things so that only if you find a
process that's busy (for a few seconds) do you move the SID group into
it's own cgroup, then for idle processes you might start with the old
group per user id. Or you could try per user id for system processes
(uid < 1000) and SID for user processes. Or .. or .. some complicated
cgroups deamon that can do all of the above.

But in kernel space this kind of complexity feels like a bad idea. 
(probably proven bad too)

As an aside, the CPU time allocation per SID concept seems like a
pretty good complement to Con Kolivas's BF Scheduler; after all BFS
is supposed to be happier with what amounts to lower "load average"
values and if all the processes under a given SID value get treated as
one 'job' for global scheduling, that's what you get.
  (NB: Yes I know, BFS breaks cgroups)

> The big circle in the middle shows the cgroups alottment, the
> satellites show the processes inside each cgroup. The number
> on the perimeter is the SID.

> Linus Walleij

-- 
Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
                                              <http://www.debath.co.uk/>

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