From: Michal Hocko <mhocko@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christopher Lameter <cl@linux.com>,
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: Thu, 29 Aug 2019 09:39:21 +0200 [thread overview]
Message-ID: <20190829073921.GA21880@dhcp22.suse.cz> (raw)
In-Reply-To: <20190828194607.GB6590@bombadil.infradead.org>
On Wed 28-08-19 12:46:08, Matthew Wilcox wrote:
> On Wed, Aug 28, 2019 at 06:45:07PM +0000, Christopher Lameter wrote:
[...]
> > be suprising and it limits the optimizations that slab allocators may use
> > for optimizing data use. The SLOB allocator was designed in such a way
> > that data wastage is limited. The changes here sabotage that goal and show
> > that future slab allocators may be similarly constrained with the
> > exceptional alignents implemented. Additional debugging features etc etc
> > must all support the exceptional alignment requirements.
>
> While I sympathise with the poor programmer who has to write the
> fourth implementation of the sl*b interface, it's more for the pain of
> picking a new letter than the pain of needing to honour the alignment
> of allocations.
>
> 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.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-08-29 7:39 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 [this message]
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: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=20190829073921.GA21880@dhcp22.suse.cz \
--to=mhocko@kernel.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=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 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).