Hi! > > > Hmm, I don't know too much about aio, but is it possible to succeed with > > > io_getevents if we didn't first do a submit? It looks like the contexts > > > are looked up out of current->mm, so I don't think we need this call > > > here. > > > > > > Otherwise, this is neat. > > > > Good question. I know nothing, either. :) > > > > My thought was that any process *trying* to do aio stuff of any kind > > is going to be really confused if it gets checkpointed. Or, it might > > try to submit an aio right after it checks the list of them. I > > thought it best to be cautious and say, if you screw with aio, no > > checkpointing for you! > > as long as there's total transparency and the transition from CR-capable > to CR-disabled state is absolutely safe and race-free, that should be > fine. > > I expect users to quickly cause enough pressure to reduce the NOCR areas > of the kernel significantly ;-) > > In the long run, could we expect a (experimental) version of hibernation > that would just use this checkpointing facility to hibernate? That would > be way cool for users and for testing: we could do transparent kernel > upgrades/downgrades via this form of hibernation, between CR-compatible > kernels (!). Well, if we could do that, I guess we could also use CR to 'hibernate' your desktop then continue on your notebook. And yes that sounds cool. > Pie in the sky for sure, but way cool: it could propel Linux kernel > testing to completely new areas - new kernels could be tried > non-intrusively. (as long as a new kernel does not corrupt the CR data > structures - so some good consistency and redundancy checking would be > nice in the format!) Well, for simple apps, it should not be that hard... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers