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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/