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.
Attachment:
pgpdcY9sYMckk.pgp
Description: PGP signature
_______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
