On Sun, Mar 29, 2020 at 04:04:59PM +0200, Martijn Coenen wrote: > Configuring a loop device for a filesystem that is located at an offset > currently requires calling LOOP_SET_FD and LOOP_SET_STATUS(64) > consecutively. This has some downsides. > > The most important downside is that it can be slow. Here's setting > up ~70 regular loop devices on an x86 Android device: > > vsoc_x86:/system/apex # time for i in `seq 30 100`; > do losetup -r /dev/block/loop$i com.android.adbd.apex; done > 0m01.85s real 0m00.01s user 0m00.01s system > > Here's configuring ~70 devices in the same way, but with an offset: > > vsoc_x86:/system/apex # time for i in `seq 30 100`; > do losetup -r -o 4096 /dev/block/loop$i com.android.adbd.apex; done > 0m03.40s real 0m00.02s user 0m00.03s system > > This is almost twice as slow; the main reason for this slowness is that > LOOP_SET_STATUS(64) calls blk_mq_freeze_queue() to freeze the associated > queue; this requires waiting for RCU synchronization, which I've > measured can take about 15-20ms on this device on average. > > A more minor downside of having to do two ioctls is that on devices with > max_part > 0, the kernel will initiate a partition scan, which is > needless work if the image is at an offset. > > This change introduces a new ioctl to combine setting the backing file > together with the offset, which avoids the above problems. Adding more > parameters could be a consideration, but offset appears to be the only > commonly used parameter that is required for accessing the device > safely. The new ioctl LOOP_SET_FD_WITH_OFFSET looks not generic enough, could you consider to add one ioctl LOOP_SET_FD_AND_STATUS to cover both SET_FD and SET_STATUS so that using two ioctl() to setup loop can become deprecated finally? Thanks, Ming
