linux-kernel - Re: [patch] slub: default min_partial to at least highest cpus per node

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 7 Apr 2009 13:09:06 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
cc:	Christoph Lameter <cl@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] slub: default min_partial to at least highest cpus per
  node

On Tue, 7 Apr 2009, Pekka Enberg wrote:

> > I'd be just as happy with the following, although it would require changing
> > MIN_PARTIAL to be greater than its default of 5 if a node supports more cpus
> > for optimal performance (the old patch did that automatically up to
> > MAX_PARTIAL).
> 
> Hmm but why not move ->min_partial to struct kmem_cache_node as I suggested
> and make sure it's adjusted properly as with nr_cpus_node()?
> 

Sure, that's also possible except we'd lose the ability to tune 
min_partial with /sys/kernel/slab/cache/min_partial, unless it would then 
change n->min_partial for each N_NORMAL_MEMORY node.  We lack an interface 
to change the per-node min_partial.

If you think that's acceptable, I'd be just as satisfied with that 
approach as long as all archs have valid cpu_to_node() mappings at the 
time of CPU_UP_PREPARE.

Aside: we're lacking in the documentation of these sysfs tunables such as 
remote_node_defrag_ratio to begin with, the only way to figure out what it 
does is by reading the code or making assumptions based on its name.  I'd 
be happy to add some documentation but it'd be good to keep it separate 
from Documentation/vm/slub.txt.
--
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/