On 2018-08-13 17:58, Kevin Wolf wrote: > Am 13.08.2018 um 17:11 hat Max Reitz geschrieben: >>>> My personal opinion is this: Most users should be fine with 8 GB of >>>> randomly accessible image space (this may be wrong). Whenever a user >>>> does have an application that uses more than 8 GB, they are probably in >>>> an area where they want to do some performance tuning anyway. Requiring >>>> them to set l2-cache-full in that case seems reasonable to me. >>> >>> In principle, I'd agree. I'd even say that management tools should >>> always explicitly set those options instead of relying on our defaults. >>> But management tools have been ignoring these options for a long time >>> and keep doing so. >>> >>> And honestly, if you can't spend a few megabytes for the caches, it's >>> just as reasonable that you should set l2-cache to a lower value. You'll >>> need some more tweaking anyway to reduce the memory footprint. >> >> It isn't, because as I explained above, it is more reasonable to expect >> people to find out about disk options because their disk performance is >> abysmal than because their RAM is exhausted. >> >> I would like to say "but it is nearly as reasonable", but I really don't >> think so. > > Maybe in a perfect world, finding the option when their disk performance > is abysmal is what users would do. In this world, they either just use > raw and scream for backing files and dirty bitmaps and whatnot for raw, > or they just directly go to some other hypervisor. > > Realistically, the cache options don't exist. They are hard to discover > in the QEMU command line and management tools don't support them. > > Conclusion: We're doomed to find a one-size-fits-all default that works > well in all common use cases, including benchmarks. We can try and make > it adapt to the situation, but we can't reasonably expect users to > manually override it.
OK, saying both is unreasonable is something I can get behind. >>> Our choice of a >>> default should reflect that, especially considering that we only use >>> the memory on demand. If your image is only 32 GB, you'll never use more >>> than 4 MB of cache. >> >> Well, OK, yes. This is an especially important point when it really is >> about hosts that have limited memory. In those cases, users probably >> won't run huge images anyway. >> >>> And if your image is huge, but only access part of >>> it, we also won't use the full 32 MB. >> >> On Linux. O:-) > > No, on any system where qemu_try_blockalign() results in a COW zero > page. OK, yes, but why would you only ever access part of it? Then you might just as well have created a smaller disk from the beginning. > The Linux-only addition is returning memory even after an access. > >> So it's good that you have calmed my nerves about how this might be >> problematic on Linux systems (it isn't in practice, although I disagree >> that people will find qcow2 to be the fault when their memory runs out), >> but you haven't said anything about non-Linux systems. I understand >> that you don't care, but as I said here, this was my only substantial >> concern anyway. > > I don't actually think it's so bad to keep the cache permanently > allocated, but I wouldn't object to a lower default for non-Linux hosts > either. 1 MB may still be a little too low, 4 MB (covers up to 32 GB) > might be more adequate. My typical desktop VMs are larger than 8 GB, but > smaller than 32 GB. Will your typical desktop VMs gain anything from the cache covering more than 8 GB? Anyway, I certainly won't complain about 4 MB. (My point here is that on non-Linux systems, qemu probably does not have users who have use cases where they need to access 256 GB of disk simultaneously. Probably not even more than 8 GB. If you want to increase the cache size there to 4 MB, fine, I think that won't hurt. But 32 MB might hurt, and I don't think on non-Linux systems there are users who would benefit from it -- specifically because your "typical desktop VM" wouldn't benefit from it.) Max
signature.asc
Description: OpenPGP digital signature