Re: [Feature] x86_64 page tracking for Stratus servers

[Nick Piggin <nickpiggin@yahoo.com.au>]

Andi Kleen wrote:

>>Silly question, why can't you do all this from stop_machine_run context (or
>>your SMI) that doesn't have to worry about other CPUs dirtying memory?
>>
>
>Because that would be too slow for continuous mirroring.
>
>You can't go through 10+GB of virtual memory (or more with shared 
>memory because the scan has to be virtual) in an interrupt.
>
>The only sane way is to do it continuously.
>

Presumably it is not continuous but there are checkpoints, and in the
worst case, enforcement of a checkpoint will require an SMI.

But OK, heuristically I'm sure it is much quicker to already have most
memory saved. I guess this is a requirement otherwise they would have
done it the obvious way... but my question is just about what exact
requirement does this satisfy that a stop_machine would not.

>
>>[*] Though if it gets included, it would not stop me lamenting the
>>proliferation of complexities to support *tiny* obscure userbases. Can
>>we wait until your hardware is smart enough to snoop the cc? :)
>>
>
>
>My guess is that if we had a generic memory mirror subsystem other people would
>find uses for it too. e.g. a lot of systems support spare DIMMs these days and mirroring
>some memory to it seems like a smart idea. That means normally the hardware
>does it, but perhaps some stuff can be done better by doing it in software.
>
>Or it is also a bit similar to the algorithms Xen uses for live migration.
>If that was implemented on the kernel level something like this might 
>be useful too. I think OpenVZ has some kind of migration support, but it's
>currently not live.
>

Yep, I'm not saying it couldn't be useful.

Send instant messages to your online friends http://au.messenger.yahoo.com