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