Re: [PATCH 2/3] slqb: Treat pages freed on a memoryless node aslocal node

[Christoph Lameter]

On Fri, 18 Sep 2009, Mel Gorman wrote:

> --- a/mm/slqb.c
> +++ b/mm/slqb.c
> @@ -1726,6 +1726,7 @@ static __always_inline void __slab_free(struct kmem_cache *s,
>  	struct kmem_cache_cpu *c;
>  	struct kmem_cache_list *l;
>  	int thiscpu = smp_processor_id();
> +	int thisnode = numa_node_id();

thisnode must be the first reachable node with usable RAM. Not the current
node. cpu 0 may be on node 0 but there is no memory on 0. Instead
allocations fall back to node 2 (depends on policy effective as well. The
round robin meory policy default on bootup may result in allocations from
different nodes as well).

>  	c = get_cpu_slab(s, thiscpu);
>  	l = &c->list;
> @@ -1733,12 +1734,14 @@ static __always_inline void __slab_free(struct kmem_cache *s,
>  	slqb_stat_inc(l, FREE);
>
>  	if (!NUMA_BUILD || !slab_numa(s) ||
> -			likely(slqb_page_to_nid(page) == numa_node_id())) {
> +			likely(slqb_page_to_nid(page) == numa_node_id() ||
> +			!node_state(thisnode, N_HIGH_MEMORY))) {

Same here.

Note that page_to_nid can yield surprising results if you are trying to
allocate from a node that has no memory and you get some fallback node.

SLAB for some time had a bug that caused list corruption because of this.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/