linux-kernel - Re: [RFC] slub: ARCH_SLAB_MINALIGN defaults to 8 on x86

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

Message-ID: <alpine.DEB.2.00.1002041019300.28165@router.home>
Date:	Thu, 4 Feb 2010 10:42:53 -0600 (CST)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Richard Kennedy <richard@....demon.co.uk>
cc:	penberg <penberg@...helsinki.fi>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>
Subject: Re: [RFC] slub: ARCH_SLAB_MINALIGN defaults to 8 on x86_32. is this
 too big?

On Wed, 3 Feb 2010, Richard Kennedy wrote:

> gives me this output :-
> 32 bit : size = 12 , offset of l = 4
> 64 bit : size = 16 , offset of l = 8
>
> Doesn't that suggest that it would be safe to use sizeof(void *) ?
> (at least on x86 anyway).

Maybe. But the rule of thumb is to align objects by their size which we
would be violating.

A 64 bit object may span multiple cachelines if aligned to a 32 bit
boundary. Which may result in nasty surprise because the object can no
longer be read and written from memory in an atomic way. If there is
a guarantee that no 64 bit operation ever occurs then it may be
fine.

Fetching a 64 bit object that straddles a cacheline boundary also requires
2 fetches instead of one to read the object which can increase the
cache footprint of functions accessing the structure.

Slab allocators (aside from SLOB which is rarely used) assume the minimal
alignment to be sizeof(unsigned long long).

> We end up with a large number of buffer_heads and as they are pretty
> small an extra 4 bytes does make a significant difference.
> On my 64 bit machine I often see thousands of pages of buffer_heads, so
> squeezing a few more per page could be a considerable saving.

On your 64 bit machine you wont be able to do the optimization that you
are talking about.

The buffer head structure is already fairly big so this wont make too much
of a difference.

--
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/