| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] map memory holes with same page
Surprisingly, resume from hibernate is very fast. Maybe windows knows the pages
are already scrubbed or something...
I've asked the "don't hibernate these pages" question on ntdev but I think
they're sick of my absurd questions :)
Sent from my iPhone
On 23/05/2011, at 20:37, "Tim Deegan" <Tim.Deegan@xxxxxxxxxx> wrote:
> At 11:29 +0100 on 23 May (1306150145), James Harper wrote:
>> I guess the only way to solve this is to stop every access hitting an
>> emulation. Either I can map a common read-only page into every hole
>> (which doesn't sound like a workable solution based on feedback so far),
>> or Xen could keep a common read-only page and map it into a hole every
>> time it is accessed (and then move the page when another hole is
>> accessed), which would reduce the problem to emulation on the first time
>> a different hole is accessed...
>
> That's pretty ugly, though. Is there really no way to tell Windows not
> to bother hibernating your ballooned-out memory? Surely there must be
> equivalent cases in real hardware: GART framebuffers and so on?
>
> What happens when Windows tries to load all your ballooned memory back
> in on resume, btw? Will it uncompress all those frames back onto
> non-existent RAM? (i.e. would we have to have this scratch frame be
> writable - and if so would we need to properly discard writes to
> correctly emulate missing RAM?)
>
> Cheers,
>
> Tim.
>
> --
> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Principal Software Engineer, Xen Platform Team
> Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home