block script performance

block script performance

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

Hi,

Some time ago I've done an analysis what's the easiest way to improve VM
startup time, and one of the things that really stands out is block
script. VM with 4 disks can take up to 2s on waiting for block scripts.
A while ago I proposed a patch[1] that short-circuits the block script for
the simplest case - already existing block device. There is also similar
slightly more complex but common case - a file-based disk, needing a
loop device.

While there are several ways I can fix this in Qubes-specific
configuration, I'd like to have a solution useful for upstream too. And
for loop devices it would be especially useful, as the Linux API here
has a _huge_ potential for all kind of races (resulting for example in a
wrong disk being connected to a VM). Currently those races are avoided
by the block script by taking a global lock, which also adds to the
performance issues...
Furthermore, I'd like a solution that is compatible with driver domains
(backend in a distinct place than the toolstack), preferably using the
same code path for both (to reduce regression risk, because most test
only dom0 case...).

Recently I've talked with Demi (in cc) about it, and we came to a conclusion
that it should be somewhere in libxl, in a place that is also called in
`xl devd` (to cover non-dom0 case). 
I think I know libxl well enough to find the right place to plug this
in, but I'd like to ask first, if this would be acceptable in upstream
libxl. Note this will be Linux-specific (both because of loop devices
part, but also because of writing xen-blkback specific xenstore entry).

[1] https://xen.markmail.org/thread/ytikjjbs4kpihzi5

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]