Messages in this thread | | | Subject | Re: Freezer Patches. | From | Nigel Cunningham <> | Date | Thu, 02 Jun 2005 08:08:29 +1000 |
| |
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/
| |