lkml.org 
[lkml]   [2017]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: v4.9, 4.4-final: 28 bioset threads on small notebook, 36 threads on cellphone
    On Mon, Feb 06 2017 at  9:49pm -0500,
    Kent Overstreet <kent.overstreet@gmail.com> wrote:

    > On Mon, Feb 06, 2017 at 04:47:24PM -0900, Kent Overstreet wrote:
    > > On Mon, Feb 06, 2017 at 01:53:09PM +0100, Pavel Machek wrote:
    > > > Still there on v4.9, 36 threads on nokia n900 cellphone.
    > > >
    > > > So.. what needs to be done there?
    >
    > > But, I just got an idea for how to handle this that might be halfway sane, maybe
    > > I'll try and come up with a patch...
    >
    > Ok, here's such a patch, only lightly tested:
    >
    > -- >8 --
    > Subject: [PATCH] block: Make rescuer threads per request_queue, not per bioset
    >
    > Note: this patch is very lightly tested.
    >
    > Also, trigger rescuing whenever with bios on current->bio_list, instead
    > of only when we block in bio_alloc_bioset(). This is more correct, and
    > should result in fewer rescuer threads.
    >
    > XXX: The current->bio_list plugging needs to be unified with the
    > blk_plug mechanism.
    >
    > TODO: If we change normal request_queue drivers to handle arbitrary size
    > bios by processing requests incrementally, instead of splitting bios,
    > then we can get rid of rescuer threads from those devices.

    Hi Kent,

    I really appreciate you working on this further. Thanks.

    As I think you're probably already aware, a long standing issue with the
    per bio_set rescuer is this bug (which manifests in dm-snapshot
    deadlocks): https://bugzilla.kernel.org/show_bug.cgi?id=119841

    Please also see this patch header, from a private branch from a while
    ago, that describes the problem in detail:
    http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/commit/?h=wip&id=cd2c760b5a609e2aaf3735a7b9503a953535c368

    Would welcome your consideration of that BZ as you think further and/or
    iterate on this line of work.

    Mike

    \
     
     \ /
      Last update: 2017-02-07 18:14    [W:4.339 / U:0.352 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site