On Thu, 2012-03-15 at 10:36 +0100, Paolo Bonzini wrote: > Changing across guest boots is a minor problem, but changing across > migration must be avoided at all costs. > > BTW, after this discussion I think we can instead report > discard_granularity = 512 and discard_zeroes_data=0 and get most of the > benefit, at least on file-backed storage.
Are you going to report that to guests all the time, or only when the host supports discard? If you don't report it all the time, you could still be "changing across migration". If you do report it all the time, then you're incurring a performance penalty on systems that don't support discard, as the guest will be sending discard requests that QEMU has to throw away (but by which time some work has been wasted). And either way, what you're proposing means that users with discard_zeros_data = 1 hosts can't get the (albeit small) benefits of that because some other QEMU user might want to do a migration across heterogeneous storage. The more I think about this, the more it seems like we just need to make this configurable. Then people that, because of migration concerns, want to advertise lowest-common-denominator storage to their guests can do so (just like they already can and likely do advertise a lowest-common-denominator CPU). Everyone else can get whatever their host supports (just like they do with CPUs). Adding configuration options also means that developers can use QEMU to test guest discard support in various ways. Finally, I see your proposal of advertising fixed discard support to guests (regardless of which set of values is chosen) out of line with the existing QEMU precedent with CPUs as well as the design decision used for discard in the Linux kernel (which passes the values all the way up the stack). While this doesn't inherently mean it's a bad design, I think QEMU should tread carefully. -- Richard
signature.asc
Description: This is a digitally signed message part
