From: Christopher Lameter <cl@linux.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Sterba <dsterba@suse.cz>, Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Ming Lei <ming.lei@redhat.com>,
Dave Chinner <david@fromorbit.com>,
Matthew Wilcox <willy@infradead.org>,
"Darrick J . Wong" <darrick.wong@oracle.com>,
Christoph Hellwig <hch@lst.de>,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-block@vger.kernel.org,
James Bottomley <James.Bottomley@HansenPartnership.com>,
linux-btrfs@vger.kernel.org, Roman Gushchin <guro@fb.com>,
Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [PATCH v2 2/2] mm, sl[aou]b: guarantee natural alignment for kmalloc(power-of-two)
Date: Thu, 26 Sep 2019 00:14:44 +0000 (UTC) [thread overview]
Message-ID: <alpine.DEB.2.21.1909260005060.1508@www.lameter.com> (raw)
In-Reply-To: <20190924165425.a79a2dafbaf37828a931df2b@linux-foundation.org>
On Tue, 24 Sep 2019, Andrew Morton wrote:
> I agree it's a bit regrettable to do this but it does appear that the
> change will make the kernel overall a better place given the reality of
> kernel development.
No it wont.
- It will only work for special cases like the kmalloc array
without extras like metadata at the end of objects.
- It will be an inconsistency in the alignments provided by the allocator.
- It will cause us in the future to constantly consider these exceptional
alignments in the maintenance of the allocators.
- These alignments are only needed in exceptional cases but with the patch
we will provide the alignment by default even if the allocating subsystem
does not need it.
- We have mechanisms to detect alignment problems using debug kernels and
debug options that have been available for years. These were not used for
testing in these cases it seems before the patches hit mainline. Once in
mainly someone ran a debug kernel and found the issue.
> Given this, have you reviewed the patch for overall implementation
> correctness?
Yes, the patch is fine.
> I'm wondering if we can avoid at least some of the patch's overhead if
> slab debugging is disabled - the allocators are already returning
> suitably aligned memory, so why add the new code in that case?
As far as I know this patch is not needed given that we have had the
standards for alignments for a long time now.
Why would the allocators provide specially aligned memory just based on
the size of an object? This is weird and unexpected behavior.
next prev parent reply other threads:[~2019-09-26 0:14 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-26 11:16 [PATCH v2 0/2] guarantee natural alignment for kmalloc() Vlastimil Babka
2019-08-26 11:16 ` [PATCH v2 1/2] mm, sl[ou]b: improve memory accounting Vlastimil Babka
2019-08-26 11:16 ` [PATCH v2 2/2] mm, sl[aou]b: guarantee natural alignment for kmalloc(power-of-two) Vlastimil Babka
2019-08-28 18:45 ` Christopher Lameter
2019-08-28 18:45 ` Christopher Lameter
2019-08-28 19:46 ` Matthew Wilcox
2019-08-28 22:24 ` Dave Chinner
2019-08-29 7:56 ` Vlastimil Babka
2019-08-30 0:29 ` Dave Chinner
2019-08-29 7:39 ` Michal Hocko
2019-08-30 17:41 ` Christopher Lameter
2019-08-30 17:41 ` Christopher Lameter
2019-09-01 0:52 ` Matthew Wilcox
2019-09-03 20:13 ` Christopher Lameter
2019-09-03 20:13 ` Christopher Lameter
2019-09-03 20:53 ` Matthew Wilcox
2019-09-04 5:19 ` Christoph Hellwig
2019-09-04 6:40 ` Ming Lei
2019-09-04 7:20 ` Vlastimil Babka
2019-09-04 19:31 ` Christopher Lameter
2019-09-04 19:31 ` Christopher Lameter
2019-09-23 16:36 ` Vlastimil Babka
2019-09-23 17:17 ` David Sterba
2019-09-23 17:51 ` Darrick J. Wong
2019-09-24 20:47 ` cl
2019-09-24 20:47 ` cl
2019-09-24 20:51 ` Matthew Wilcox
2019-09-24 20:55 ` cl
2019-09-24 20:55 ` cl
2019-09-26 13:02 ` David Sterba
2019-09-24 21:19 ` Vlastimil Babka
2019-09-24 21:53 ` Dave Chinner
2019-09-24 22:21 ` Darrick J. Wong
2019-09-24 20:52 ` cl
2019-09-24 20:52 ` cl
2019-09-24 23:54 ` Andrew Morton
2019-09-25 7:17 ` Vlastimil Babka
2019-09-26 0:16 ` Christopher Lameter
2019-09-26 0:16 ` Christopher Lameter
2019-09-26 0:14 ` Christopher Lameter [this message]
2019-09-26 0:14 ` Christopher Lameter
2019-09-26 7:41 ` Vlastimil Babka
2019-09-28 1:12 ` Christopher Lameter
2019-09-28 1:12 ` Christopher Lameter
2019-09-30 13:32 ` Matthew Wilcox
2019-09-23 17:54 ` Roman Gushchin
2019-09-30 8:06 ` Christoph Hellwig
2019-09-30 9:23 ` Michal Hocko
2019-09-30 9:32 ` Kirill A. Shutemov
2019-09-23 18:57 ` Matthew Wilcox
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1909260005060.1508@www.lameter.com \
--to=cl@linux.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=dsterba@suse.cz \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.