linux-kernel - Re: [RFD] Task counter: cgroup core feature or cgroup subsystem? (was Re: [PATCH 0/8 v3] cgroups: Task counter subsystem)

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALdu-PA3+u-v1fj-DQuC-zyJ4Ud0Xi0sq0zcB0DLNcR_TMT6XQ@mail.gmail.com>
Date:	Tue, 23 Aug 2011 09:07:59 -0700
From:	Paul Menage <paul@...lmenage.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Kay Sievers <kay.sievers@...y.org>, Li Zefan <lizf@...fujitsu.com>,
	Tim Hockin <thockin@...kin.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Aditya Kali <adityakali@...gle.com>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: [RFD] Task counter: cgroup core feature or cgroup subsystem? (was
 Re: [PATCH 0/8 v3] cgroups: Task counter subsystem)

On Thu, Aug 18, 2011 at 7:33 AM, Frederic Weisbecker <fweisbec@...il.com> wrote:
>
> So the problem with the task counter as a subsystem is that you could
> mount it in your systemd cgroups hierarchy but then it's not anymore
> available for those who want to use containers.

Another possible option is something that I prototyped a couple of
years ago, but dropped due to lack of compelling need and demand - the
ability to have subsystems that can be bound on multiple subsystems at
once. See

http://lkml.indiana.edu/hypermail/linux/kernel/0907.0/00574.html
http://lkml.indiana.edu/hypermail/linux/kernel/0907.0/00576.html
http://lkml.indiana.edu/hypermail/linux/kernel/0907.0/00577.html

It's applicable to subsystems whose state isn't tied to any specific
single resource in the kernel outside of cgroups (so e.g. the CPU
scheduler couldn't be usefully multi-bindable, since the CPU cgroup
state is tied to the machine's single CPU scheduler).

In the end I didn't work further on it, since it seemed that most
things that needed to be available to multiple hierarchies could more
simply be added to the core cgroups subsystem and automatically be
available on all hierarchies. But the point about tracking overhead
for fork/exit is certainly something that could make this worthwhile.

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