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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101116205043.GG27235@tango.0pointer.de>
Date:	Tue, 16 Nov 2010 21:50:43 +0100
From:	Lennart Poettering <mzxreary@...inter.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Dhaval Giani <dhaval.giani@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Mike Galbraith <efault@....de>,
	Vivek Goyal <vgoyal@...hat.com>,
	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, 16.11.10 11:45, Linus Torvalds (torvalds@...ux-foundation.org) wrote:

> 
> On Tue, Nov 16, 2010 at 11:27 AM, Dhaval Giani <dhaval.giani@...il.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.
--
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/