Re: [Qemu-devel] [PATCH v7 6/9] qcow2: Increase the default upper limit on the L2 cache size

[Kevin Wolf <kwolf@redhat.com>]

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

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.

> >                                                         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.

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.

Kevin

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