linux-kernel - Re: [slub p4 2/7] slub: Remove useless statements in __slab

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

Message-ID: <alpine.DEB.2.00.1108201340270.3008@localhost6.localdomain6>
Date:	Sat, 20 Aug 2011 13:44:41 +0300 (EEST)
From:	Pekka Enberg <penberg@...nel.org>
To:	Christoph Lameter <cl@...ux.com>
cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	rientjes@...gle.com
Subject: Re: [slub p4 2/7] slub: Remove useless statements in __slab_alloc

On Tue, 9 Aug 2011, Christoph Lameter wrote:
> Two statements in __slab_alloc() do not have any effect.
>
> 1. c->page is already set to NULL by deactivate_slab() called right before.
>
> 2. gfpflags are masked in new_slab() before being passed to the page
>   allocator. There is no need to mask gfpflags in __slab_alloc in particular
>   since most frequent processing in __slab_alloc does not require the use of a
>   gfpmask.
>
> Cc: torvalds@...ux-foundation.org
> Signed-off-by: Christoph Lameter <cl@...ux.com>

Linus wasn't actually on the CC of the email.

> ---
> mm/slub.c |    4 ----
> 1 file changed, 4 deletions(-)
>
> Index: linux-2.6/mm/slub.c
> ===================================================================
> --- linux-2.6.orig/mm/slub.c	2011-08-01 11:03:15.000000000 -0500
> +++ linux-2.6/mm/slub.c	2011-08-01 11:04:06.385859038 -0500
> @@ -2064,9 +2064,6 @@ static void *__slab_alloc(struct kmem_ca
> 	c = this_cpu_ptr(s->cpu_slab);
> #endif
>
> -	/* We handle __GFP_ZERO in the caller */
> -	gfpflags &= ~__GFP_ZERO;
> -

This is the part Linus felt strongly about in the past. It's not needed 
now that we mask GFP flags in new_slab() and the code path is pretty hot 
on workloads where SLAB traditionally has had better performance.

> 	page = c->page;
> 	if (!page)
> 		goto new_slab;
> @@ -2163,7 +2160,6 @@ debug:
>
> 	c->freelist = get_freepointer(s, object);
> 	deactivate_slab(s, c);
> -	c->page = NULL;
> 	c->node = NUMA_NO_NODE;
> 	local_irq_restore(flags);
> 	return object;
>
>
--
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/