lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180521144703.GA19303@redhat.com>
Date:   Mon, 21 May 2018 10:47:03 -0400
From:   Mike Snitzer <snitzer@...hat.com>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     Kent Overstreet <kent.overstreet@...il.com>,
        linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        hch@...radead.org, colyli@...e.de, darrick.wong@...cle.com,
        clm@...com, bacik@...com, linux-xfs@...r.kernel.org,
        drbd-dev@...ts.linbit.com, linux-btrfs@...r.kernel.org,
        linux-raid@...r.kernel.org, neilb@...e.com
Subject: Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On Mon, May 21 2018 at 10:36am -0400,
Jens Axboe <axboe@...nel.dk> wrote:

> On 5/21/18 8:31 AM, Mike Snitzer wrote:
> > On Mon, May 21 2018 at 10:19am -0400,
> > Jens Axboe <axboe@...nel.dk> wrote:
> > 
> >> On 5/21/18 8:03 AM, Mike Snitzer wrote:
> >>> On Sun, May 20 2018 at  6:25pm -0400,
> >>> Kent Overstreet <kent.overstreet@...il.com> wrote:
> >>>
> >>>> Jens - this series does the rest of the conversions that Christoph wanted, and
> >>>> drops bioset_create().
> >>>>
> >>>> Only lightly tested, but the changes are pretty mechanical. Based on your
> >>>> for-next tree.
> >>>
> >>> By switching 'mempool_t *' to 'mempool_t' and 'bio_set *' to 'bio_set'
> >>> you've altered the alignment of members in data structures.  So I'll
> >>> need to audit all the data structures you've modified in DM.
> >>>
> >>> Could we get the backstory on _why_ you're making this change?
> >>> Would go a long way to helping me appreciate why this is a good use of
> >>> anyone's time.
> >>
> >> Yeah, it's in the first series, it gets rid of a pointer indirection.
> > 
> > "Allows mempools to be embedded in other structs, getting rid of a
> > pointer indirection from allocation fastpaths."
> > 
> > So this is about using contiguous memory or avoiding partial allocation
> > failure?  Or both?
> > 
> > Or more to it?  Just trying to fully appreciate the theory behind the
> > perceived associated benefit.
> 
> It's about avoiding a pointer indirection. Instead of having to
> follow a pointer to get to that struct, it's simple offset math off
> your main structure.
> 
> > I do think the increased risk of these embedded bio_set and mempool_t
> > themselves crossing cachelines, or struct members that follow them doing
> > so, really detracts from these types of changes.
> 
> Definitely something to look out for, though most of them should be
> per-dev structures and not in-flight structures. That makes it a bit
> less sensitive. But can't hurt to audit the layouts and adjust if
> necessary. This is why it's posted for review :-)

This isn't something that is easily caught upfront.  Yes we can all be
busy little beavers with pahole to audit alignment.  But chances are
most people won't do it.

Reality is there is potential for a regression due to false sharing to
creep in if a hot struct member suddenly starts straddling a cacheline.
That type of NUMA performance killer is pretty insidious and somewhat
tedious to hunt down even when looking for it with specialized tools:
https://joemario.github.io/blog/2016/09/01/c2c-blog/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ