lkml.org 
[lkml]   [2007]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [linux-pm] Re: Hibernation considerations
Date
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]
\
 
 \ /
  Last update: 2007-07-23 05:15    [W:0.677 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site