[Top][All Lists]

[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

From: Alberto Garcia
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] qcow2: do lazy allocation of the L2 cache
Date: Fri, 08 May 2015 11:00:08 +0200
User-agent: Notmuch/0.13.2 (http://notmuchmail.org) Emacs/23.2.1 (i486-pc-linux-gnu)

On Fri 24 Apr 2015 03:04:06 PM CEST, Kevin Wolf <address@hidden> wrote:

>> >> I think it would be nice to have a way to free unused cache
>> >> entries after a while.
>> >
>> > Do you think mmap plus a periodic timer would work?
>> >
>> > I'm hesitant about changes like this because they make QEMU more
>> > complex, slow down the guest, and make the memory footprint
>> > volatile.  But if a simple solution addresses the problem, then I'd
>> > be happy.
>> I understand. One possible approach would be to use the timer only if
>> the cache size requested by the user is large, so
>>  1) we only try to save memory when the amount of memory to save is
>>     significant.
>>  2) we don't make the default scenario slower.
>> I'll try to see if I can come up with a good solution (and with more
>> numbers).
> I suspect that at this point, Anthony would have reminded us about
> separation of policy and mechanism. The very least we need is some
> option to control the policy (probably defaulting to no automatic
> cache size changes).

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.

One possible solution would be madvise() with MADV_DONTNEED, and that's
rather simple to use, but I'm unsure about its portability.

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


reply via email to

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