linux-kernel - RCU fanout leaf balancing

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

Message-ID: <544B4A4C.5070807@numascale.com>
Date:	Sat, 25 Oct 2014 14:59:24 +0800
From:	Daniel J Blueman <daniel@...ascale.com>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
CC:	Steffen Persvold <sp@...ascale.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: RCU fanout leaf balancing

Hi Paul,

Finding earlier reference to increasing RCU fanout leaf for the purpose 
of "decrease[ing] cache-miss overhead for large systems", would your 
suggestion be to increase the value to the next hierarchy core-count 
above 16?

If we have say 32 interconnected 48-core servers; 3 sockets of dual-node 
8-core Opteron 6300s, so 1536 cores in all. Latency across the coherent 
interconnect is O(100x) higher than the internal Hypertransport 
interconnect, so if we set RCU_FANOUT_LEAF to 48 to keep leaf-checking 
local to one Hypertransport fabric, what wisdom would one use for 
RCU_FANOUT? 4x leaf?

Or, would it be more cache-friendly to set RCU_FANOUT_LEAF to 8 and 
RCU_FANOUT to 48?

Many thanks,
   Daniel
-- 
Daniel J Blueman
Principal Software Engineer, Numascale
--
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/