[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] [PATCH] qcow2: do lazy allocation of the L
Re: [Qemu-devel] [Qemu-block] [PATCH] qcow2: do lazy allocation of the L2 cache
Fri, 08 May 2015 13:47:16 +0200
Notmuch/0.13.2 (http://notmuchmail.org) Emacs/23.2.1 (i486-pc-linux-gnu)
On Fri 08 May 2015 11:47:00 AM CEST, Kevin Wolf wrote:
>> There's also the problem that with a single chunk of memory for all
>> cache tables it's not so easy to free individual entries.
> That's one of the reasons why I suggested to fix the problem by using
> mmap() for the individual entries rather than allocating one big
Yeah but how portable mmap() is? Does it work in Windows?
>> One possible solution would be madvise() with MADV_DONTNEED, and
>> that's rather simple to use, but I'm unsure about its portability.
> Probably not portable at all, but the worst that can happen is that a
> cache doesn't shrink, i.e. behaves like today. Seems good enough.
We actually have qemu_madvise() and QEMU_MADV_DONTNEED, so if the system
does not support the operation then it's just a no-op. However that
means that if we expose some sort of API to configure the cache
expiration time, it would only work on some platforms.
>> > The other option would be to let the management tool change the cache
>> > size options at runtime (and as it happens, my current bdrv_reopen()
>> > overhaul allows just that - except that a QMP interface isn't planned
>> > yet), but I'm not sure if it has enough information to make good
>> > decisions. If we know what the criteria are, they could possibly be
>> > exposed, though.
>> But what would you do there? Recreate the whole cache?
> Recreating the cache is the easiest solution (and it is what my reopen
> patches do) and the overhead is probably neglegible as long as you
> don't resize the cache all the time.
> If we really need it, resizing the cache while maintaining its content
> would be possible, too.
I agree that the overhead of recreating the cache is probably negligible
so there's no need to make it more complex.
But as you say I don't think it's easy for the management tool to make
good decisions. If we have to expose the relevant information so it can
be done I think we would end up with an unnecessarily complex solution.
A simple way to set the expiration time of cache entries seems like a
much easier solution, both from the implementation and the user point of