On Fri, Apr 16, 2010 at 10:48:09AM -0500, Scott Wood wrote: > Anton Vorontsov wrote: > >On Thu, Apr 15, 2010 at 03:05:08PM -0500, Scott Wood wrote: > >>Kumar Gala wrote: > >>>On Apr 15, 2010, at 1:45 PM, Anton Vorontsov wrote: > >>>>Kumar, > >>>> > >>>>According to patchwork, this is now delegated to you. Do you > >>>>have any objections to merge this? > >>>Would like Scott's Ack. > >>I think we need to save IACn, DACn, DBCRn, > > > >Does the kernel actually need these registers? I mean, they're > >saved per thread anyway. > > > >>PID0, > > > >Kernel clears it early at boot, why would we save it? > > What context are we in when we suspend, and what context is expected > after resume? If we're guaranteed not to be on a thread that cares > about any of this, then OK.
Yeah, we're in the kernel context on suspend and resume. > >>and USPRG0. > > > >Currently this isn't used at all. > > Was thinking that it's up to userspace whether to use it or not -- > though it ought to be saved on thread switch instead. > > >>Might want to also save TLB1 contents, and maybe things like HIDn, > >>cache registers, etc. -- I don't think they're changeable post-boot > >>currently, but it'd be good to avoid surprises if that were to > >>change. > > > >Hm. I don't really like the idea of doing things 'just in case', > >it just adds a code which functionality isn't tested, and which > >we will might never actually need. > > The intent was to reduce dependencies between the suspend code and > what the rest of the kernel does -- it's likely that someone adding > some runtime manipulation of one of these things (e.g. hugetlbfs > modifying TLB1) would not think to check suspend/hibernation code. > It would still be somewhat tested, in that you would see problems if > you restored the wrong values (just not if you failed to restore at > all). Yep, I understand the intent, though, I'd like 'git reset --hard this_commit' to bring a minimal, but still fully functional hibernate, without unneeded cruft. We might add more savings/restores later [or sooner, when needed], but that won't matter that much since we'll have a point in the git history with that minimal support. I could even implement more savings and restores on top of this patch, but really, I don't see a hurry in doing this now. :-) So that's why I don't. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
