linux-kernel - Re: [patch] sched: fix sched-domains partitioning by 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] [thread-next>] [day] [month] [year] [list]

Message-Id: <200710030329.57274.nickpiggin@yahoo.com.au>
Date:	Wed, 3 Oct 2007 03:29:56 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Paul Jackson <pj@....com>
Cc:	Ingo Molnar <mingo@...e.hu>, akpm@...ux-foundation.org,
	menage@...gle.com, linux-kernel@...r.kernel.org, dino@...ibm.com,
	cpw@....com
Subject: Re: [patch] sched: fix sched-domains partitioning by cpusets

On Wednesday 03 October 2007 19:39, Paul Jackson wrote:
> > in any case i'd like to see the externally visible API get in foremost -
> > and there now seems to be agreement about that. (yay!) Any internal
> > shaping of APIs can be done flexibly between cpusets and the scheduler.
>
> Yup - though Nick and I will have to agree to -some- internal interface
> between the cpuset and sched code, at least for the moment.
>
> At least, if we thrash about on this, we won't be changing the externally
> visible API around.  We'll just continue driving Andrew nuts, not our
> users - that's an improvement.

OK look, I don't want to hold up progress. I do like to ask these questions
and be difficult if I think there might be a better way and/or to make sure
you've thought about all the angles. I'm not volunteering to maintain
cpusets and I'm not as close to the customers who care as you.

Obviously what your patches do here is a lot closer to "the right thing"
than cpus_exclusive. And the worst problem they'll cause is to add
cruft to cpusets.c.

So I'll keep persuing the other subthread for the same reasons, but aside
from implementation nits, I don't know if it is worth holding up a merge.
-
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/