linux-kernel - Re: Tiny cpusets -- cpusets for small systems?

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

Date:	Thu, 13 Mar 2008 00:01:38 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Paul Jackson <pj@....com>
Cc:	Paul Menage <menage@...gle.com>, kosaki.motohiro@...fujitsu.com,
	maxk@...lcomm.com, alan@...rguk.ukuu.org.uk, adilger@....com,
	akpm@...ux-foundation.org, daniel.spang@...il.com, mingo@...e.hu,
	jonathan@...masters.org, marcelo@...ck.org, pavel@....cz,
	a.p.zijlstra@...llo.nl, riel@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: Tiny cpusets -- cpusets for small systems?

On Sat, Feb 23, 2008 at 09:57:52AM -0600, Paul Jackson wrote:
> Paul M wrote:
> > I'm don't think that either of these would be enough to justify big
> > changes to cpusets or cgroups, although eliminating bloat is always a
> > good thing.
> 
> My "tiny cpuset" idea doesn't so much eliminate bloat, as provide a
> thin alternative, along side of the existing fat alternative.  So
> far as kernel source goes, it would get bigger, not smaller, with now
> two CONFIG choices for cpusets, fat or tiny.
> 
> The odds are, however, given that one of us has just promised not to
> code this, and the other of us doesn't figure it's worth it, this
> idea will not live long.  Someone would have to step up from the
> embedded side with a coded version that saved a nice chunk of memory
> (from their perspective) to get this off the ground, and no telling
> whether even that would meet with a warm reception.
> 
This has actually been on my TODO list for awhile, though not quite in
the way that you outlined in your initial post. A good reason for why
cpusets are fat at the moment is largely because there's no isolation or
configurability of individual features supported and exposed, leaving one
with an all-or-nothing scenario.

Both the SMP and NUMA bits are fairly orthogonal, and I think isolating
those and making each configurable would already help trim things down
quite a bit (ie, nodemask handling, scheduler domains, etc.). The
filesystem bits are not really that heavy comparatively, so rather than
working on a tiny cpuset implementation, simply splitting up the existing
implementation seems like a much saner approach, and one that can be done
incrementally.

While we're on the topic of cpuset reform, co-processors are another
thing that cpusets is in pretty good shape to handle (particularly in
terms of carving up large grid and dataflow processors and things of that
nature, which we do have customer use cases for in embedded space today).

I'll try to follow up to this thread with an initial patch series in the
not-too-distant future.
--
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/