Messages in this thread |  | | Date | Wed, 06 Sep 2006 19:36:16 +1000 | From | Nick Piggin <> | Subject | Re: [Feature] x86_64 page tracking for Stratus servers |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |