[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190814114646.GA14561@ming.t460p>
Date: Wed, 14 Aug 2019 19:46:48 +0800
From: Ming Lei <ming.lei@...hat.com>
To: Martijn Coenen <maco@...roid.com>
Cc: axboe@...nel.dk, linux-block@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>,
Greg KH <gregkh@...uxfoundation.org>, kernel-team@...roid.com,
Narayan Kamath <narayan@...gle.com>,
Dario Freni <dariofreni@...gle.com>,
Nikita Ioffe <ioffe@...gle.com>,
Jiyong Park <jiyong@...gle.com>,
Martijn Coenen <maco@...gle.com>
Subject: Re: [PATCH] RFC: loop: Avoid calling blk_mq_freeze_queue() when
possible.
On Wed, Aug 14, 2019 at 01:38:25PM +0200, Martijn Coenen wrote:
> On Wed, Aug 14, 2019 at 1:34 PM Ming Lei <ming.lei@...hat.com> wrote:
> > Another candidate is to not switch to q_usage_counter's percpu mode
> > until loop becomes Lo_bound, and this way may be more clean.
>
> Thanks! I had considered this too, but thought it a bit risky to mess
> with the init flag from the loop driver. Maybe we could delay
blk_queue_init_done() is only called in blk_queue_init_done() for
this purpose, so this approach should be fine, IMO.
> switching q_usage_counter to per-cpu mode in the block layer in
> general, until the first request comes in?
This approach may not help your issue on loop, IO request comes
just after disk is added, such as by systemd, or reading partition table.
However, loop only starts to handle IO really after it becomes 'Lo_bound'.
thanks,
Ming
Powered by blists - more mailing lists