Re: [Feature] x86_64 page tracking for Stratus servers
From: Nick Piggin
Date: Wed Sep 06 2006 - 05:33:30 EST
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/