linux-kernel - Re: [RFC][PATCH 0/2] reworking load_balance

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:	Thu, 14 Feb 2008 12:15:44 -0600
From:	Paul Jackson <pj@....com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	vatsa@...ux.vnet.ibm.com, dhaval@...ux.vnet.ibm.com,
	arjan@...radead.org, mingo@...e.hu, tglx@...utronix.de,
	ghaskins@...ell.com, linux-kernel@...r.kernel.org,
	a.p.zijlstra@...llo.nl
Subject: Re: [RFC][PATCH 0/2] reworking load_balance_monitor

Peter wrote of:
> the lack of rd->load_balance.

Could you explain to me a bit what that means?

Does this mean that the existing code would, by default (default being
a single sched domain, covering the entire system's CPUs) load balance
across the entire system, but with your rework, not so load balance
there?  That seems unlikely.

In any event, from my rather cpuset-centric perspective, there are only
two common cases to consider.

 1. In the default case, build_sched_domains() gets called once,
    at init, with a cpu_map of all non-isolated CPUs, and we should
    forever after load balance across all those non-isolated CPUs.

 2. In some carefully managed systems using the per-cpuset
    'sched_load_balance' flags, we tear down that first default
    sched domain, by calling detach_destroy_domains() on it, and we
    then setup some number of sched_domains (typically in the range
    of two to ten, though I suppose we should design to scale to
    hundreds of sched domains, on systems with thousands of CPUs)
    by additional calls to build_sched_domains(), such that their
    CPUs don't overlap (pairwise disjoint) and such that the union
    of all their CPUs may, or may not, include all non-isolated CPUs
    (some CPUs might be left 'out in the cold', intentionally, as
    essentially additional isolated CPUs.)  We would then expect load
    balancing within each of these pair-wise disjoint sched domains,
    but not between one of them and another.

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