linux-kernel - Re: [RFC] cpuset: remove sched domain hooks from cpusets

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

Date:	Thu, 9 Nov 2006 02:59:28 -0800
From:	Paul Jackson <pj@....com>
To:	Andrew Morton <akpm@...l.org>
Cc:	nickpiggin@...oo.com.au, suresh.b.siddha@...el.com,
	mbligh@...gle.com, menage@...gle.com, Simon.Derr@...l.net,
	linux-kernel@...r.kernel.org, dino@...ibm.com,
	rohitseth@...gle.com, holt@....com, dipankar@...ibm.com,
	Christoph Lameter <clameter@....com>
Subject: Re: [RFC] cpuset: remove sched domain hooks from cpusets

Andrew,

This patch is currently residing in your *-mm stack, as:

  cpuset-remove-sched-domain-hooks-from-cpusets.patch

If it's easy for you to keep track of, I'd like to ask that you don't
push this to Linus until Dinakar and I (with the consent of various
mm experts) settle on the replacement mechanism for dealing with
sched domain partitioning (or whatever that turns in to.)

At the rate Dinakar and I are progressing, this likely means that this
"... remove ... hooks ..." patch will be sitting in *-mm through the
2.6.20 work, and go on to Linus for 2.6.21.

There are some folks actually depending on this mechanism, such as
some real time folks using this to inhibit load balancing on their
isolated CPUs.  It would be polite not to yank out one mechanism
before its replacement is available.

If this sounds like a pain, or you'd just rather not baby sit this in
*-mm that long, then I'd have you drop the patch before I had you send
it to Linus without an accompanying replacement.

All else equal, I kind of like leaving this patch in *-mm for now, as
it puts a stake in the ground, indicating that the current connection
between the per-cpuset "cpu_exclusive" flag and sched domain partitions
is sitting on death row.

There seems to be a general concensus that death row is a good place for
that.

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