From: Vlastimil Babka <email@example.com>
To: Christopher Lameter <firstname.lastname@example.org>
Cc: email@example.com, Pekka Enberg <firstname.lastname@example.org>,
David Rientjes <email@example.com>,
Joonsoo Kim <firstname.lastname@example.org>,
Ming Lei <email@example.com>,
Dave Chinner <firstname.lastname@example.org>,
Matthew Wilcox <email@example.com>,
"Darrick J . Wong" <firstname.lastname@example.org>,
Christoph Hellwig <email@example.com>, Michal Hocko <firstname.lastname@example.org>,
Subject: Re: [RFC 0/2] guarantee natural alignment for kmalloc()
Date: Thu, 21 Mar 2019 08:42:02 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
On 3/20/19 7:20 PM, Christopher Lameter wrote:
>>> 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.
> "In practice" refers to the current way that slab allocators arrange
> objects within the page. They are free to do otherwise if new ideas come
> up for object arrangements etc.
> The slab allocators already may have to store data in addition to the user
> accessible part (f.e. for RCU or ctor). The "natural alighnment" of a
> power of 2 cache is no longer as you expect for these cases. Debugging is
> not the only case where we extend the object.
For plain kmalloc() caches, RCU and ctors don't apply, right.
>> 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.
> As explained before there is nothing "natural" here. Doing so restricts
> future features
Well, future features will have to deal with the existing named caches
created with specific alignment.
> and creates a mess within the allocator of exceptions for
> debuggin etc etc (see what happened to SLAB).
SLAB could be fixed, just nobody cares enough I guess. If I want to
debug wrong SL*B usage I'll use SLUB.
> "Natural" is just a
> simplistic thought of a user how he would arrange power of 2 objects.
> These assumption should not be made but specified explicitly.
Patch 1 does this explicitly for plain kmalloc(). It's unrealistic to
add 'align' parameter to plain kmalloc() as that would have to create
caches on-demand for 'new' values of align parameter.
>>> I think its valuable that alignment requirements need to be explicitly
>> That's still possible for named caches created by kmem_cache_create().
> So lets leave it as it is now then.
That however doesn't work well for the xfs/IO case where block sizes are
not known in advance:
next prev parent reply other threads:[~2019-03-21 7:42 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
2019-03-20 18:20 ` Christopher Lameter
2019-03-21 7:42 ` Vlastimil Babka [this message]
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
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).