On Wed, Nov 09, 2022 at 04:45:18PM +0100, Markus Armbruster wrote: > Daniel P. Berrangé <berra...@redhat.com> writes: > > > On Wed, Nov 09, 2022 at 04:26:53PM +0100, Markus Armbruster wrote: > >> Daniel P. Berrangé <berra...@redhat.com> writes: > >> > >> > On Mon, Nov 07, 2022 at 06:32:01PM +0100, Andrew Jones wrote: > >> > >> [...] > >> > >> >> Padding is a good idea, but too much causes other problems. When > >> >> building > >> >> lightweight VMs which may pull the firmware image from a network, > >> >> AArch64 VMs require 64MB of mostly zeros to be transferred first, which > >> >> can become a substantial amount of the overall boot time[*]. Being able > >> >> to > >> >> create images smaller than the total flash device size, but still add > >> >> some > >> >> pad for later growth, seems like the happy-medium to shoot for. > >> > > >> > QEMU configures the firmware using -blockdev, > >> > >> Yes, even though the devices in question are not block devices. > >> > >> > so can use any file > >> > format that QEMU supports at the block layer. IOW, you can store > >> > the firmware in a qcow2 file and thus you will never fetch any > >> > of the padding zeros to be transferred. That said I'm not sure > >> > that libvirt supports anything other than a raw file today. > >> > >> Here's another idea. The "raw" format supports exposing a slice of the > >> underlying block node (options @offset and @size). It could support > >> padding. Writing to the padding should then grow the underlying node. > >> > >> Taking a step back to look at the bigger picture... there are three > >> issues, I think: > >> > >> (A) Storing padding on disk is wasteful. > >> > >> Use a file system that supports sparse files, or an image format > >> that can represent the padding efficiently. > >> > >> (B) Reading padding into memory is wasteful. > >> > >> Matters mostly when a network is involved. Use an image format that > >> can represent the padding efficiently. > >> > >> (C) Dirtying memory for padding is wasteful. > >> > >> I figure KSM could turn zero-padding into holes. > >> > >> We could play with mmap() & friends. > >> > >> Other ideas? > > > > Is (C) actually a separate issue ? I thought it was simply the > > result of (B) ? ie if we skip reading the zero padding, we won't > > be dirtying the memory with lots of zeros. we'll have mmap'd the > > full 64 MB, but most won't be paged in since we wouldn't write > > the zeros to it. Only if the guest writes to those areas do we > > need to then flush it back out. > > I expressed myself poorly. All three are related, but there's still a > distinction between each of them in my thinking. > > Say we use an image format that compresses data. Represents the padding > efficiently. Storage on disk is efficient (A), and so is reading it > (B). Trouble is decompressing it to memory dirties the memory unless we > take care not to write all-zero pages (C). > > Clearer now?
Ok yeah, so reading can be efficient, but if the reader doesn't pay attention to where the holes are, it'll dirty memory anyway. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
