[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.