From: Matthew Wilcox <willy@infradead.org>
To: Christopher Lameter <cl@linux.com>
Cc: Michal Hocko <mhocko@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
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>,
"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
Subject: Re: [PATCH v2 2/2] mm, sl[aou]b: guarantee natural alignment for kmalloc(power-of-two)
Date: Sat, 31 Aug 2019 17:52:05 -0700 [thread overview]
Message-ID: <20190901005205.GA2431@bombadil.infradead.org> (raw)
In-Reply-To: <0100016ce39e6bb9-ad20e033-f3f4-4e6d-85d6-87e7d07823ae-000000@email.amazonses.com>
On Fri, Aug 30, 2019 at 05:41:46PM +0000, Christopher Lameter wrote:
> On Thu, 29 Aug 2019, Michal Hocko wrote:
> > > There are many places in the kernel which assume alignment. They break
> > > when it's not supplied. I believe we have a better overall system if
> > > the MM developers provide stronger guarantees than the MM consumers have
> > > to work around only weak guarantees.
> >
> > I absolutely agree. A hypothetical benefit of a new implementation
> > doesn't outweigh the complexity the existing code has to jump over or
> > worse is not aware of and it is broken silently. My general experience
> > is that the later is more likely with a large variety of drivers we have
> > in the tree and odd things they do in general.
>
> The current behavior without special alignment for these caches has been
> in the wild for over a decade. And this is now coming up?
In the wild ... and rarely enabled. When it is enabled, it may or may
not be noticed as data corruption, or tripping other debugging asserts.
Users then turn off the rare debugging option.
> There is one case now it seems with a broken hardware that has issues and
> we now move to an alignment requirement from the slabs with exceptions and
> this and that?
Perhaps you could try reading what hasa been written instead of sticking
to a strawman of your own invention?
> If there is an exceptional alignment requirement then that needs to be
> communicated to the allocator. A special flag or create a special
> kmem_cache or something.
The only way I'd agree to that is if we deliberately misalign every
allocation that doesn't have this special flag set. Because right now,
breakage happens everywhere when these debug options are enabled, and
the very people who need to be helped are being hurt by the debugging.
next prev parent reply other threads:[~2019-09-01 0:52 UTC|newest]
Thread overview: 40+ 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 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-09-01 0:52 ` Matthew Wilcox [this message]
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-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:51 ` Matthew Wilcox
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 23:54 ` Andrew Morton
2019-09-25 7:17 ` Vlastimil Babka
2019-09-26 0:16 ` Christopher Lameter
2019-09-26 0:14 ` Christopher Lameter
2019-09-26 7:41 ` Vlastimil Babka
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=20190901005205.GA2431@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--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=mhocko@kernel.org \
--cc=ming.lei@redhat.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
/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 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).