On Thu, Sep 14, 2017 at 09:29:28AM +0200, Peter Krempa wrote: > On Thu, Sep 14, 2017 at 13:02:46 +0800, Liu Qing wrote: > > On Wed, Sep 13, 2017 at 01:20:03PM +0200, Peter Krempa wrote: > > > On Wed, Sep 13, 2017 at 17:21:23 +0800, Liu Qing wrote: > > [...] > > > > [1] There's discussion I can link to for other tuning parameters. The > > > gist is that allowing users to set something withoug giving them > > > guidance is pointless since they might not use it. Also if the guidance > > > is strict (e.g. a formula, libvirt or qemu should set the defaults > > > properly and not force users to do the calculation) > > The guidance could be found in doc/qcow2-cache.txt in qemu source code. > > As John Ferlan suggested I have added the file locaton in formatdomain.html.in. > > Well, if the guidance is absolute (use this cache size and it's okay) > then we should implement it automatically (don't allow users > to set it.) > > I'm asking whether there are some catches why not to do it automatically. > E.g whether there's an possibility that users would do something *else* > as described by the document and what would be the reasons for it. I think there is some trade off between the cache size and performance. Otherwise qemu does not need to export these parameters to user, they could do the automation in qemu. The guidance only let the user know how much disk space is coverred by caches, and how much memory will be needed to cover all disk spaces. User should do their own decision to choose a right size. But if the user is using the current version of libvirt, they could not set the value even if they know what's the proper value. For example if the user may need a LUN which need high IOPS, he could set the cache to cover all disk spaces. And in another situation, he needs a large capacity,for example 4T, but low perfermance LUN, then he could set the l2 cache size to a value much less than 512M. > > One of the reasons might be memory consumption of the cache as it > looks like you need 1 MiB of memory to fully cover a 8GiB image. Yes, as I said above. > > Also the problem is that those parameters are qemu-isms so we should be > aware when modelling them in the XML since they can change and may not > map well to any other technology. Currently the new element is added as a child elemnt of driver, and the driver type needs to be qcow2. Also add this kind information in the doc. > > Also how does the cache impact read-performance from the backing layers? > We might need to set the cache for the backing layers as well. I have a peek at the latest qemu code and the backing layers will have the same cache size value as the top volume. And this will reduce metadata read count if the table is already in the memory. Also more memory will consumed. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
