| 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
| ||
|
Message-ID: <4A0ADD88.9080705@redhat.com> Date: Wed, 13 May 2009 10:47:36 -0400 From: Rik van Riel <riel@...hat.com> To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com> CC: LKML <linux-kernel@...r.kernel.org>, linux-mm <linux-mm@...ck.org>, Andrew Morton <akpm@...ux-foundation.org>, Christoph Lameter <cl@...ux-foundation.org> Subject: Re: [PATCH 4/4] zone_reclaim_mode is always 0 by default KOSAKI Motohiro wrote: > Subject: [PATCH] zone_reclaim_mode is always 0 by default > > Current linux policy is, if the machine has large remote node distance, > zone_reclaim_mode is enabled by default because we've be able to assume to > large distance mean large server until recently. > > Unfrotunately, recent modern x86 CPU (e.g. Core i7, Opeteron) have P2P transport > memory controller. IOW it's NUMA from software view. > > Some Core i7 machine has large remote node distance and zone_reclaim don't > fit desktop and small file server. it cause performance degression. > > Thus, zone_reclaim == 0 is better by default. sorry, HPC gusy. > you need to turn zone_reclaim_mode on manually now. I'll believe that it causes a performance regression with the old zone_reclaim behaviour, however the way you tweaked zone_reclaim should make it behave a lot better, no? -- All rights reversed. -- 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/
Powered by blists - more mailing lists