[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v7 6/9] qcow2: Increase the default upper limit

From: Max Reitz
Subject: Re: [Qemu-block] [PATCH v7 6/9] qcow2: Increase the default upper limit on the L2 cache size
Date: Mon, 13 Aug 2018 18:08:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]