From: Bart Van Assche <bvanassche@acm.org>
To: Martijn Coenen <maco@android.com>, axboe@kernel.dk
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
gregkh@linuxfoundation.org, kernel-team@android.com,
narayan@google.com, dariofreni@google.com, ioffe@google.com,
jiyong@google.com, maco@google.com
Subject: Re: [PATCH] RFC: loop: Avoid calling blk_mq_freeze_queue() when possible.
Date: Wed, 14 Aug 2019 08:29:49 -0700 [thread overview]
Message-ID: <29990045-b05e-1411-a5c2-32e735265a04@acm.org> (raw)
In-Reply-To: <20190814103244.92518-1-maco@android.com>
On 8/14/19 3:32 AM, Martijn Coenen wrote:
> Since Android Q, the creation and configuration of loop devices is in
> the critical path of device boot. We found that the configuration of
> loop devices is pretty slow, because many ioctl()'s involve freezing the
> block queue, which in turn needs to wait for an RCU grace period. On
> Android devices we've observed up to 60ms for the creation and
> configuration of a single loop device; as we anticipate creating many
> more in the future, we'd like to avoid this delay.
>
> This allows LOOP_SET_BLOCK_SIZE to be called before the loop device has
> been bound; since the block queue is not running at that point, we can
> avoid the expensive freezing of the queue.
>
> On a recent x86, this patch yields the following results:
>
> ===
> Call LOOP_SET_BLOCK_SIZE on /dev/loop0 before being bound
> ===
> ~# time ./set_block_size
>
> real 0m0.002s
> user 0m0.000s
> sys 0m0.002s
>
> ===
> Call LOOP_SET_BLOCK_SIZE on /dev/loop0 after being bound
> ===
> ~# losetup /dev/loop0 fs.img
> ~# time ./set_block_size
>
> real 0m0.008s
> user 0m0.000s
> sys 0m0.002s
>
> Over many runs, this is a 4x improvement.
>
> This is RFC because technically it is a change in behavior; before,
> calling LOOP_SET_BLOCK_SIZE on an unbound device would return ENXIO, and
> userspace programs that left it in their code despite the returned
> error, would now suddenly see the requested value effectuated. I'm not
> sure whether this is acceptable.
>
> An alternative might be a CONFIG option to set the default block size to
> another value than 512. Another alternative I considered is allowing the
> block device to be created with a "frozen" queue, where we can manually
> unfreeze the queue when all the configuration is done. This would be a
> much larger code change, though.
Hi Martijn,
Is the loop driver used in Android Q to make a file on a filesystem
visible as a block device or rather to make a subset of a block device
visible as a block device? In the latter case, have you considered to
use the dm-linear driver instead? I expect that the overhead per I/O of
dm-linear will be lower than that of the loop driver.
Bart.
next prev parent reply other threads:[~2019-08-14 15:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-14 10:32 [PATCH] RFC: loop: Avoid calling blk_mq_freeze_queue() when possible Martijn Coenen
2019-08-14 11:33 ` Ming Lei
2019-08-14 11:38 ` Martijn Coenen
2019-08-14 11:46 ` Ming Lei
2019-08-15 14:57 ` Martijn Coenen
2019-08-15 16:34 ` Ming Lei
2019-08-15 19:08 ` Martijn Coenen
2019-08-19 9:06 ` Martijn Coenen
2019-08-19 9:26 ` Martijn Coenen
2019-08-14 15:29 ` Bart Van Assche [this message]
2019-08-15 14:49 ` Martijn Coenen
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=29990045-b05e-1411-a5c2-32e735265a04@acm.org \
--to=bvanassche@acm.org \
--cc=axboe@kernel.dk \
--cc=dariofreni@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=ioffe@google.com \
--cc=jiyong@google.com \
--cc=kernel-team@android.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maco@android.com \
--cc=maco@google.com \
--cc=narayan@google.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;
as well as URLs for NNTP newsgroup(s).