From: Shaohua Li <shli@kernel.org>
To: Ming Lei <ming.lei@redhat.com>
Cc: linux-block@vger.kernel.org, axboe@kernel.dk, Kernel-team@fb.com,
Shaohua Li <shli@fb.com>
Subject: Re: [PATCH V2 2/2] block/loop: allow request merge for directio mode
Date: Wed, 30 Aug 2017 15:06:16 -0700 [thread overview]
Message-ID: <20170830220616.7dqv5lz4rd4qgs2q@kernel.org> (raw)
In-Reply-To: <20170830064339.GB1024@ming.t460p>
On Wed, Aug 30, 2017 at 02:43:40PM +0800, Ming Lei wrote:
> On Tue, Aug 29, 2017 at 09:43:20PM -0700, Shaohua Li wrote:
> > On Wed, Aug 30, 2017 at 10:51:21AM +0800, Ming Lei wrote:
> > > On Tue, Aug 29, 2017 at 08:13:39AM -0700, Shaohua Li wrote:
> > > > On Tue, Aug 29, 2017 at 05:56:05PM +0800, Ming Lei wrote:
> > > > > On Thu, Aug 24, 2017 at 12:24:53PM -0700, Shaohua Li wrote:
> > > > > > From: Shaohua Li <shli@fb.com>
> > > > > >
> > > > > > Currently loop disables merge. While it makes sense for buffer IO mode,
> > > > > > directio mode can benefit from request merge. Without merge, loop could
> > > > > > send small size IO to underlayer disk and harm performance.
> > > > >
> > > > > Hi Shaohua,
> > > > >
> > > > > IMO no matter if merge is used, loop always sends page by page
> > > > > to VFS in both dio or buffer I/O.
> > > >
> > > > Why do you think so?
> > >
> > > do_blockdev_direct_IO() still handles page by page from iov_iter, and
> > > with bigger request, I guess it might be the plug merge working.
> >
> > This is not true. directio sends big size bio directly, not because of plug
> > merge. Please at least check the code before you complain.
>
> I complain nothing, just try to understand the idea behind,
> never mind, :-)
>
> >
> > > >
> > > > > Also if merge is enabled on loop, that means merge is run
> > > > > on both loop and low level block driver, and not sure if we
> > > > > can benefit from that.
> > > >
> > > > why does merge still happen in low level block driver?
> > >
> > > Because scheduler is still working on low level disk. My question
> > > is that why the scheduler in low level disk doesn't work now
> > > if scheduler on loop can merge?
> >
> > The low level disk can still do merge, but since this is directio, the upper
> > layer already dispatches request as big as possible. There is very little
> > chance the requests can be merged again.
>
> That is true, but these requests need to enter scheduler queue and
> be tried to merge again, even though it is less possible to succeed.
> Double merge may take extra CPU utilization.
>
> Looks it doesn't answer my question.
>
> Without this patch, the requests dispatched to loop won't be merged,
> so they may be small and their sectors may be continuous, my question
> is why dio bios converted from these small loop requests can't be
> merged in block layer when queuing these dio bios to low level device?
loop thread doesn't have plug there. Even we have plug there, it's still a bad
idea to do the merge in low level layer. If we run direct_IO for every 4k, the
overhead is much much higher than bio merge. The direct_IO will call into fs
code, take different mutexes, metadata update for write and so on.
next prev parent reply other threads:[~2017-08-30 22:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-24 19:24 [PATCH V2 0/2] block/loop: improve performance Shaohua Li
2017-08-24 19:24 ` [PATCH V2 1/2] block/loop: set hw_sectors Shaohua Li
2017-08-29 9:35 ` Ming Lei
2017-08-24 19:24 ` [PATCH V2 2/2] block/loop: allow request merge for directio mode Shaohua Li
2017-08-29 9:56 ` Ming Lei
2017-08-29 15:13 ` Shaohua Li
2017-08-30 2:51 ` Ming Lei
2017-08-30 4:43 ` Shaohua Li
2017-08-30 6:43 ` Ming Lei
2017-08-30 22:06 ` Shaohua Li [this message]
2017-08-31 3:25 ` Ming Lei
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=20170830220616.7dqv5lz4rd4qgs2q@kernel.org \
--to=shli@kernel.org \
--cc=Kernel-team@fb.com \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=shli@fb.com \
/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