linux-kernel - Re: [PATCH] cpuset and sched domains: sched_load

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]

Date:	Wed, 3 Oct 2007 05:17:29 -0700
From:	Paul Jackson <pj@....com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	akpm@...ux-foundation.org, menage@...gle.com,
	linux-kernel@...r.kernel.org, dino@...ibm.com, cpw@....com,
	mingo@...e.hu
Subject: Re: [PATCH] cpuset and sched domains: sched_load_balance flag

Nick wrote:
> OK, so I don't exactly understand you either. To make it simple, can
> you give a concrete example of a cpuset hierarchy that wouldn't
> work?

It's more a matter of knowing how my third party batch scheduler
coders think.  They will be off in some corner of their code with a
cpuset in hand that they know is just being used to hold inactive
(paused) tasks, and they can likely be persuaded to mark those cpusets
as not being in need of any wasted CPU cycles load balancing them.

But these inactive cpusets will overlap in unknown (to them at
the time, in that piece of code) ways with other cpusets holding
active jobs, and there is no chance, unless it is a matter of major
performance impact, that they will be in any position to comment on
the proper partitioning of the sched domains on all the CPUs under the
control of their batch scheduler, much less comment on the partitioning
of the rest of the system.

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