[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[2]: [Qemu-devel] Storing code caching
From: |
Igor Shmukler |
Subject: |
Re[2]: [Qemu-devel] Storing code caching |
Date: |
Thu, 08 Jul 2004 23:42:14 +0400 |
> I think a more interesting idea is to 'virtualize' the memory.... That
> is, we provide a means for a guest to request more physical memory and
> to be able to release that memory back to the host... Perhaps also some
> method in which the host can warn the guest of low memory situations so
> that the guest can be more aggressive on memory reclaiming.
>
> Of course, this optimization would require changes to the guest OS to
> take advantage of it but it would mean that the guest would no longer
> have to worry about swap pressures and that the host can perform the
> swapping on behalf of the guest - this would be much faster as the
> guest's virtual hardware will be much slower to swap to than the hosts'
> real hardware.
>
> This communication mechinism has to be well defined and audited as it
> could potentially allow the guest the ability to 'break out' of it's
> box. I would suggest that the best way would be to make the
> communication channel look like some piece of hardware - but there are
> other options available - such as magic opcodes...
VMWare developed a solution for this issue a while ago. They described a
technique called balooning at the OSDI'02. Their approach allows to address
issues you raised without modifications to the guest OS.
All the is needed is a baloon driver.
I don't see how it would help with caching execution profile, though.
IS.