Messages in this thread | | | Date | Sat, 11 Oct 2008 15:48:03 +0200 | From | Pavel Machek <> | Subject | Re: [RFC][PATCH 2/2] first callers of process_deny_checkpoint() |
| |
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
| |