Re: Helping drivers to work without the freezer

Rafael J. Wysocki
2008-03-08T21:56:20Z

On Saturday, 8 of March 2008, Alan Stern wrote:
> This idea just occurred to me. It may or may not end up being useful,
> and I don't have any specific applications in mind yet.
>
> System sleeps are supposed to be transparent to userspace. An I/O
> request submitted just before the sleep starts should be blocked until
> after the system wakes up.
>
> Without the freezer to do this blocking for them, drivers will have to
> do it themselves. So when a driver is about to carry out an I/O
> operation, it has to insure that the operation is mutually exclusive
> with sleeping.
>
> One way to do this is by a private mutex, which would protect both the
> block of code doing the I/O and the suspend routine. One for each
> device; that's a lot of new mutexes.
>
> My idea is instead to have the PM core provide a new pair of routines
> for use by drivers. Something like "thread_not_sleepable()" and
> "thread_sleepable()".
>
> The first routine would be called by a driver before starting to do
> I/O, while no locks are held. If a sleep transition had already
> started, the routine would block until the sleep was over. Otherwise,
> the thread would be marked with a NOT_SLEEPABLE flag until the second
> routine was called. When the PM core wanted to start a system sleep
> it would have to check whether any threads were marked NOT_SLEEPABLE,
> and wait until none of them were.
>
> This could make drivers a little simpler. It would mean less code to
> modify, and it would remove one entry from the messy I/O vs. unbind vs.
> suspend synchronization problem.
>
> Comments?

Well, this is what the current freezer does with respect to kernel threads,
only the name of the flag is different. ;-)

You basically need something very similar to the current freezer in order
to implement the "PM core would have to check whether any threads were marked
NOT_SLEEPABLE, and wait until none of them were" functionality.

Thanks,
Rafael