linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [RFC][PATCH 0/7] re-shrink 'struct page' when SLUB is on.
@ 2013-12-13 23:59 Dave Hansen
  2013-12-13 23:59 ` [RFC][PATCH 1/7] mm: print more details for bad_page() Dave Hansen
                   ` (7 more replies)
  0 siblings, 8 replies; 20+ messages in thread
From: Dave Hansen @ 2013-12-13 23:59 UTC (permalink / raw)
  To: linux-kernel
  Cc: linux-mm, Pravin B Shelar, Christoph Lameter, Kirill A. Shutemov,
	Andi Kleen, Dave Hansen

SLUB depends on a 16-byte cmpxchg for an optimization.  For the
purposes of this series, I'm assuming that it is a very important
optimization that we desperately need to keep around.

In order to get guaranteed 16-byte alignment (required by the
hardware on x86), 'struct page' is padded out from 56 to 64
bytes.

Those 8-bytes matter.  We've gone to great lengths to keep
'struct page' small in the past.  It's a shame that we bloat it
now just for alignment reasons when we have extra space.  Plus,
bloating such a commonly-touched structure *HAS* to have cache
footprint implications.

These patches attempt _internal_ alignment instead of external
alignment for slub.

I also got a bug report from some folks running a large database
benchmark.  Their old kernel uses slab and their new one uses
slub.  They were swapping and couldn't figure out why.  It turned
out to be the 2GB of RAM that the slub padding wastes on their
system.

On my box, that 2GB cost about $200 to populate back when we
bought it.  I want my $200 back.

This set takes me from 16909584K of reserved memory at boot
down to 14814472K, so almost *exactly* 2GB of savings!  It also
helps performance, presumably because it touches 14% fewer
struct page cachelines.  A 30GB dd to a ramfs file:

        dd if=/dev/zero of=bigfile bs=$((1<<30)) count=30

is sped up by about 4.4% in my testing.

This is compile tested and lightly runtime tested.  I'm curious
what people think of it before we push it futher.  I believe this
gets rid of the concerns Christoph had about adding additional
branches in the fast path, although I still disagree that this
has any benefit in practice.

I also wrote up a document describing 'struct page's layout:

	http://tinyurl.com/n6kmedz

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2013-12-19 19:14 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-13 23:59 [RFC][PATCH 0/7] re-shrink 'struct page' when SLUB is on Dave Hansen
2013-12-13 23:59 ` [RFC][PATCH 1/7] mm: print more details for bad_page() Dave Hansen
2013-12-16 16:52   ` Christoph Lameter
2013-12-16 17:20     ` Andi Kleen
2013-12-13 23:59 ` [RFC][PATCH 2/7] mm: page->pfmemalloc only used by slab/skb Dave Hansen
2013-12-13 23:59 ` [RFC][PATCH 3/7] mm: slabs: reset page at free Dave Hansen
2013-12-13 23:59 ` [RFC][PATCH 4/7] mm: rearrange struct page Dave Hansen
2013-12-13 23:59 ` [RFC][PATCH 5/7] mm: slub: rearrange 'struct page' fields Dave Hansen
2013-12-13 23:59 ` [RFC][PATCH 6/7] mm: slub: remove 'struct page' alignment restrictions Dave Hansen
2013-12-14  3:13   ` Andi Kleen
2013-12-13 23:59 ` [RFC][PATCH 7/7] mm: slub: cleanups after code churn Dave Hansen
2013-12-17  0:01 ` [RFC][PATCH 0/7] re-shrink 'struct page' when SLUB is on Andrew Morton
2013-12-17  0:45   ` Dave Hansen
2013-12-17 15:17     ` Christoph Lameter
2013-12-19  0:24       ` Dave Hansen
2013-12-19  0:41         ` Andrew Morton
2013-12-19  0:48           ` Dave Hansen
2013-12-19 15:21             ` Christoph Lameter
2013-12-19 19:14           ` Dave Hansen
2013-12-18  8:51     ` Pekka Enberg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).