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  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]
Date:	Thu, 18 Nov 2010 16:42:27 -0800
From:	Linus Torvalds <>
To:	Samuel Thibault <>,
	Linus Torvalds <>,
	Mike Galbraith <>,
	Hans-Peter Jansen <>,,
	Lennart Poettering <>,,
	Dhaval Giani <>,
	Peter Zijlstra <>,
	Vivek Goyal <>,
	Oleg Nesterov <>,
	Markus Trippelsdorf <>,
	Mathieu Desnoyers <>,
	Ingo Molnar <>,
	Balbir Singh <>
Subject: Re: [RFC/RFT PATCH v3] sched: automated per tty task groups

On Thu, Nov 18, 2010 at 4:02 PM, Samuel Thibault
<> wrote:
>> If you're doing things per thread, you've already lost.
> Not per thread, per process, i.e. put threads of the same process in the
> same cgroup. Again, I would have thought that creating a cgroup is very
> lightweight in front of a fork()

Absolutely not.

We have a good light-weight fork(). We try to avoid any extra
allocations. We *definitely* don't want things at that level.

Seriously. I'd really like somebody running AIM7 just to see that even
just doing it at setsid() doesn't hurt too badly. And that's something
that happens once in a blue moon compared to fork and/or process

Once per session is about as much as is acceptable. That's the kind of
granularity we should look at. So things like "groups per user",
"groups per session", "groups per one graphical application" are good.
Not things that can happen tens of thousands of times a second.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists