archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <>
To: Christopher Lameter <>
Cc:, Pekka Enberg <>,
	David Rientjes <>,
	Joonsoo Kim <>,
	Ming Lei <>,
	Dave Chinner <>,
	Matthew Wilcox <>,
	"Darrick J . Wong" <>,
	Christoph Hellwig <>, Michal Hocko <>,,,,
Subject: Re: [RFC 0/2] guarantee natural alignment for kmalloc()
Date: Wed, 20 Mar 2019 09:48:47 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 3/20/19 1:43 AM, Christopher Lameter wrote:
> On Tue, 19 Mar 2019, Vlastimil Babka wrote:
>> The recent thread [1] inspired me to look into guaranteeing alignment for
>> kmalloc() for power-of-two sizes. Turns out it's not difficult and in most
>> configuration nothing really changes as it happens implicitly. More details in
>> the first patch. If we agree we want to do this, I will see where to update
>> documentation and perhaps if there are any workarounds in the tree that can be
>> converted to plain kmalloc() afterwards.
> This means that the alignments are no longer uniform for all kmalloc
> caches and we get back to code making all sorts of assumptions about
> kmalloc alignments.

Natural alignment to size is rather well defined, no? Would anyone ever
assume a larger one, for what reason?
It's now where some make assumptions (even unknowingly) for natural
There are two 'odd' sizes 96 and 192, which will keep cacheline size
alignment, would anyone really expect more than 64 bytes?

> Currently all kmalloc objects are aligned to KMALLOC_MIN_ALIGN. That will
> no longer be the case and alignments will become inconsistent.

KMALLOC_MIN_ALIGN is still the minimum, but in practice it's larger
which is not a problem.

Also let me stress again that nothing really changes except for SLOB,
and SLUB with debug options. The natural alignment for power-of-two
sizes already happens as SLAB and SLUB both allocate objects starting on
the page boundary. So people make assumptions based on that, and then
break with SLOB, or SLUB with debug. This patch just prevents that
breakage by guaranteeing those natural assumptions at all times.

> I think its valuable that alignment requirements need to be explicitly
> requested.

That's still possible for named caches created by kmem_cache_create().

> Lets add an array of power of two aligned kmalloc caches if that is really
> necessary. Add some GFP_XXX flag to kmalloc to make it ^2 aligned maybe?

That's unnecessary and wasteful, as the existing caches are already
aligned in the common configurations. Requiring a flag doesn't help with
the implicit assumptions going wrong. I really don't think it needs to
get more complicated than adjusting the uncommon configuration, as this
patch does.

  parent reply	other threads:[~2019-03-20  8:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-19 21:11 [RFC 0/2] guarantee natural alignment for kmalloc() Vlastimil Babka
2019-03-19 21:11 ` [RFC 1/2] mm, sl[aou]b: guarantee natural alignment for kmalloc(power-of-two) Vlastimil Babka
2019-03-19 21:11 ` [RFC 2/2] mm, sl[aou]b: test whether kmalloc() alignment works as expected Vlastimil Babka
2019-03-20  0:44   ` Christopher Lameter
2019-03-20  0:43 ` [RFC 0/2] guarantee natural alignment for kmalloc() Christopher Lameter
2019-03-20  0:53   ` David Rientjes
2019-03-20  8:48   ` Vlastimil Babka [this message]
2019-03-20 18:20     ` Christopher Lameter
2019-03-21  7:42       ` Vlastimil Babka
2019-03-22 17:52         ` Christopher Lameter
2019-04-05 17:11           ` Vlastimil Babka
2019-04-07  8:00             ` Christoph Hellwig
2019-04-09  8:07               ` Vlastimil Babka
2019-04-09  9:20                 ` Michal Hocko
2019-03-20 18:53     ` Matthew Wilcox
2019-03-20 21:48       ` Vlastimil Babka
2019-03-21  2:23         ` Matthew Wilcox
2019-03-21  7:02           ` Vlastimil Babka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).