Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: Back to the future. | Date | Sat, 28 Apr 2007 11:24:56 +0200 |
| |
On Saturday, 28 April 2007 10:50, Pavel Machek wrote: > Hi! > > > > In many ways, "at all". > > > > > > I _do_ realize the IO request queue issues, and that we cannot actually do > > > s2ram with some devices in the middle of a DMA. So we want to be able to > > > avoid *that*, there's no question about that. And I suspect that stopping > > > user threads and then waiting for a sync is practically one of the easier > > > ways to do so. > > > > > > So in practice, the "at all" may become a "why freeze kernel threads?" and > > > freezing user threads I don't find really objectionable. > > > > > > But as Paul pointed out, Linux on the old powerpc Mac hardware was > > > actually rather famous for having working (and reliable) suspend long > > > before it worked even remotely reliably on PC's. And they didn't do even > > > that. > > > > > > (They didn't have ACPI, and they had a much more limited set of devices, > > > but the whole process freezer is really about neither of those issues. The > > > wild and wacky PC hardware has its problems, but that's _one_ thing we > > > can't blame PC hardware for ;) > > > > We freeze user space processes for the reasons that you have quoted above. > > > > Why we freeze kernel threads in there too is a good question, but not for me to > > answer. I don't know. Pavel should know, I think. > > We do not want kernel threads running: > > a) they may hold some locks and deadlock suspend
Yeah, the same issue as with the hibernation and I do think it's _real_.
> b) they may do some writes to disk, leading to corruption
Hmm, is that an issue in the suspend (aka s2ram) case?
> We could solve a) by carefully auditing suspend lock usage to make > sure deadlocks are impossible even with kernel threads running.
Yes, we can, but for now it's not been done yet.
Greetings, Rafael - 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/
| |