Re: Freezer Patches.

[Nigel Cunningham <ncunningham@cyclades.com>]

Morning.

On Wed, 2005-06-01 at 23:02, Pavel Machek wrote:
> Hi!
> 
> > Here are the freezer patches. They were prepared against rc3, but I
> > think they still apply fine against rc5. (Ben, these are the same ones I
> > sent you the other day).
> 
> 304 seems ugly and completely useless for mainline

That's because you don't understand what it's doing.

The new refrigerator implementation works like this:

Userspace processes that begin a sys_*sync gain the process flag
PF_SYNCTHREAD for the duration of their syscall.

We then freeze processes in three distinct groups.

1. Userspace processes (p->mm) that don't have PF_SYNCTHREAD set are
signalled first. This causes them to enter the refrigerator, thereby
stopping them from submitting further I/O that could cause the syncing
threads to potentially spin for ever.

2. Syncing threads are signalled so that when they finish syncing (if
they haven't already), they also enter the refrigerator. Any processes
that were in group 2 but are now in group 1 are also signalled.

It is possible that no process was syncing data. We thus now call
sys_sync ourselves, to flush remaining dirty data to disk.

3. Kernel threads not needed during suspend (kjournald, eg) are frozen.

> 300: stopping softirqd seems dangerous to me... are you sure?

It's been that way for ages without any reports of deadlocks. I'm happy
to change it if it really was dangerous for some reason.

> 301: patching exit should not be neccessary. Why do you need it?

Maybe you're right. I think it's a left over from the old
implementation. I'll try removing the call and see how the freezer
survives some stress testing.

Regards,

Nigel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/