lkml.org 
[lkml]   [2010]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/RFT PATCH v3] sched: automated per tty task groups
On Tue, 16.11.10 11:45, Linus Torvalds (torvalds@linux-foundation.org) wrote:

>
> On Tue, Nov 16, 2010 at 11:27 AM, Dhaval Giani <dhaval.giani@gmail.com> wrote:
> >
> > So what do you think about something like systemd handling it. systemd
> > already does a lot of this stuff already in the form of process
> > tracking, so it is quite trivial to do this. And more happily avoids
> > all this complexity in the kernel.
>
> What complexity? Have you looked at the patch? It has no complexity anywhere.
>
> It's a _lot_ less complex than having system daemons you don't
> control. We have not had good results with that approach in the past.
> System daemons tend to cause nasty problems, and debugging them is a
> nightmare.

Well, userspace doesn't bite.

> For example: how do you do reference counting for a cgroup in user
> space, when processes fork and exit without you even knowing it? In
> kernel space, it's _trivial_. That's what kernel/autogroup.c does, and
> it has lots of support for it, because that kind of reference counting
> is exactly what the kernel does.

You can just do an rmdir from the cgroup release handler. Heck, "rmdir"
is a pretty good GC in itself, since it deletes a cgroup only if it is
empty.

> In a system daemon? Good luck with that. It's a nightmare. Maybe you
> could just poll all the cgroups, and try to remove them once a minute,
> and if they are empty it works. Or something like that. But what a
> hacky thing it would be.

Well, that nightmare already exists. It's systemd. We use the cgroup
release handler. If you ask me it's an aweful interface, but works
fine.

> And more importantly: I don't run systemd. Neither do a lot of other
> people. The way the patch does things, "it just works".

So this basically boils down to the fact that this is useful for your
particular usecase. Because you don't want to update userspace. But
don't claim this would be useful for anybody but you. It is definitely
irrelevant for the usual desktop usecase.

> Did you go to the phoronix forum to look at how people reacted to the
> phoronix article about the patch? There were a number of testers. It
> was just so _easy_ to test and set up. If you want people to run some
> specific system daemon, it immediately gets much harder to set up and
> do.

Jeez. Phoronix!

If you truly believe that the Phoronix usecase of running "make -j64"
over the kernel tree was in any way relevant in real life for anybody
but kernel developers, then I can't help you.

Lennart

--
Lennart Poettering - Red Hat, Inc.


\
 
 \ /
  Last update: 2010-11-16 21:53    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site