Messages in this thread | | | From | Nigel Cunningham <> | Subject | Re: [linux-pm] Re: Hibernation considerations | Date | Mon, 23 Jul 2007 13:11:53 +1000 |
| |
Hi.
On Monday 23 July 2007 10:04:43 Paul Mackerras wrote: > Nigel Cunningham writes: > > > I guess I want to persist because all of these issues aren't utterly > > unsolvable. It's just that we don't have the infrastructure yet to > > figure out the solutions to these issues trivially. Take, for example, > > Ever heard of the halting problem? :) It's not just a matter of > infrastructure. You very quickly get into questions that are > mathematically undecideable.
Is this the halting problem, though?
> > the locking issue. If we could call some function to say "What process > > holds this lock?", then task A could know that it's waiting on task B > > and put that information somewhere. We could then use the information > > to freeze task B before task A. > > But how would that help? If task B holds the lock, then we can't > freeze it until it's released the lock. Then the question is, what > does task B need in order to get to the point where it releases the > lock? And so on. It rapidly gets not just extremely messy, but > actually impossible to compute in general.
Take a step back for a second.
The problem we're facing now is that we're getting some userspace threads, used in processing I/O, that are functioning as exceptions to the "freeze userspace, then freezeable kernel threads" rule. They are only exceptions because of that role in processing I/O - because they're de facto kernel threads. So, if we orient our thinking more in terms of I/O processing and less in terms of the userspace/kernelspace distinction, we'll have a solution:
1) Freeze processes that aren't fs related (ie stop them generating I/O). 2) Flush pending I/O. 3) Freeze filesystems in reverse order of dependency, the primary purpose being to stop them generating further I/O on their metadata.
Locks that are being held are only being held because work is being done. If we progressively focus on threads in terms of their create/process work dependencies, we'll see that the problem isn't at all intractable.
Regards,
Nigel -- See http://www.tuxonice.net for Howtos, FAQs, mailing lists, wiki and bugzilla info. [unhandled content-type:application/pgp-signature] | |