linux-kernel - Re: boot cgroup questions

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: <20080414133902.7878cfce.pj@sgi.com>
Date:	Mon, 14 Apr 2008 13:39:02 -0500
From:	Paul Jackson <pj@....com>
To:	Max Krasnyanskiy <maxk@...lcomm.com>
Cc:	menage@...gle.com, mingo@...e.hu, a.p.zijlstra@...llo.nl,
	linux-kernel@...r.kernel.org
Subject: Re: boot cgroup questions

Max wrote:
> I mean you guys were talking about how wonderful 
> and flexible cpusets are, but we cannot seem to use the flexibility because 
> the apps are designed for a flat layout

No.  Not flat.  Not at all flat.

We routinely and normally have an interesting hierarchy of cpusets
below /dev/cpuset.  However that hierarchy is determined by the
nesting of subsets of the nodes (CPUs and/or Memory) on the system.

These subsets of nodes in the /dev/cpuset hierarchy may well map
nicely into the subsets of CPUs that can receive a particular set
of IRQs, however that map is not bijective.  Of particular interest
here, it's not injective, meaning that multiple cpusets might and
will commonly receive the same set of IRQs.  You can force this map
to be injective by elaborating the cpuset hierarchy to reflect both
this new assignment of IRQs and the (CPU and/or Memory) node subset
hiearchy that it currently reflects, but that will break code that
was expecting the directory tree below /dev/cpuset to directly and
only reflect the node hierarchy.

In less mathematically obtuse wording, sure you can add more directory
layers below /dev/cpuset, to handle IRQ assignments, but that will
break code that was expecting the /dev/cpuset directory tree to only
reflect the nesting of (CPU and/or Memory) nodes.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@....com> 1.940.382.4214
--
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/