All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Dave Chinner <david@fromorbit.com>,
	Christoph Hellwig <hch@infradead.org>,
	xfs <linux-xfs@vger.kernel.org>
Subject: Re: Broken dio refcounting leads to livelock?
Date: Tue, 08 Jan 2019 16:30:14 -0500	[thread overview]
Message-ID: <x49ef9m7s7t.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <20190108210716.GV12689@magnolia> (Darrick J. Wong's message of "Tue, 8 Jan 2019 13:07:16 -0800")

"Darrick J. Wong" <darrick.wong@oracle.com> writes:

> On Tue, Jan 08, 2019 at 03:54:23PM -0500, Jeff Moyer wrote:
>> "Darrick J. Wong" <darrick.wong@oracle.com> writes:
>> 
>> > It looks like we're issuing two bios to satisfy a particular dio.
>> > However, the first bio completes before the submitter calls finish_plug??
>> >
>> > I guess this means that blk_start_plug no longer plugs up io requests,
>> > which means that the end_io function tries to wake up the submitter
>> > before it's even had a chance to issue the second bio.
>> 
>> blk_start_plug was always a hint.  If you exceed a certain number of
>> requests (BLK_MAX_REQUEST_COUNT, which is 16) or a certain size of
>> request (BLK_PLUG_FLUSH_SIZE, which is 128k), the block layer will flush
>> the plug list.
>> 
>> > This is surprising to me, because I was under the impression that
>> > blk_{start,finish}_plug held all the bios so there was no chance that
>> > any of them would issue (let alone call end_io) before finish_plug.
>> 
>> Definitely not the case.  The plug list is just a performance
>> optimization.
>
> Ahh, fun!  I had not realized that it was merely a suggestion.
>
> $ git grep blk_start_plug Documentation/
> $ echo $?
> 1

Point taken.  ;-)  I'll write some kernel-doc text.  Hopefully
documentation in the header file will be enough?

Cheers,
Jeff

  reply	other threads:[~2019-01-08 21:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-08  0:26 Broken dio refcounting leads to livelock? Darrick J. Wong
2019-01-08  1:16 ` Darrick J. Wong
2019-01-08  3:03   ` Darrick J. Wong
2019-01-08  7:46 ` Dave Chinner
2019-01-08 20:08   ` Darrick J. Wong
2019-01-08 20:54     ` Jeff Moyer
2019-01-08 21:07       ` Darrick J. Wong
2019-01-08 21:30         ` Jeff Moyer [this message]
2019-01-08 23:12         ` Dave Chinner

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=x49ef9m7s7t.fsf@segfault.boston.devel.redhat.com \
    --to=jmoyer@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.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.