Date: Fri, 19 Sep 2008 19:50:03 +0400 From: Lev Serebryakov <lev@FreeBSD.org> To: Peter Grehan <grehan@freebsd.org> Cc: freebsd-current@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re[2]: amd opteron NUMA support Message-ID: <1161333663.20080919195003@serebryakov.spb.ru> In-Reply-To: <48D3BBFD.4040403@freebsd.org> References: <20080919120017.1D44810656A3@hub.freebsd.org> <48D3BBFD.4040403@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Peter. You wrote 19 ???????? 2008 ?., 18:49:33: >> Is anyone looking at trying to add specific support for the >> hyper-transport based numa AMD systems? > You don't have to do anything. The penalty for remote access is hidden > with caching. It's only hugely large working sets that would show the > difference, and for those, the memory is probably set up interleaved to > average out the worst-case behaviour. It is not perfectly true. New Java versions have NUMA-aware memory allocator, which interacts with OS (Solaris is best an linux is much worse in providin adequate NUMA configuration information to userland) and this gives about +15% on 4-socket Opteron system and +200% on SunFire 15K with 72 sockets (of UltraSPARC, so SunFire expirience is not too releveant for FreeBSD) on typical benchmarks. -- // Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1161333663.20080919195003>