Hi everyone,
Please look at the result of this command ...
ps jak sid
and
ps jaxk sid
Notice the grouping for the SID column.
It's been proven that this patch is a good idea, but the SID number is the
one that already provides the proper process grouping and is ALREADY
maintained by every program starter out there.
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 think this means the time for allocating a new autogroup is when the
process DETACHES from a tty not when it attaches ...
PS: Not a mailing list member; CC me if you want to reply.
--
Rob. (Robert de Bath <robert$ @ debath.co.uk>)
<http://www.debath.co.uk/>
2010/11/19 Robert de Bath <[email protected]>:
> 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/
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.
Yours,
Linus Walleij
On Sat, 20 Nov 2010, Linus Walleij wrote:
> 2010/11/19 Robert de Bath <[email protected]>:
>
>> 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/>