On Sun, May 27, 2007 at 11:45:03PM +0200, Rafael J. Wysocki wrote: > On Sunday, 27 May 2007 22:49, Matthew Garrett wrote: > > If we remove process freezing in STR, this should just work[1] without the > > need to complicate things. > > Under the (optimistic, IMO) assumption that the relevant user space task won't > block on I/O with a suspended device involved or something like this. Yeah, I forgot the footnote that was going to mention that. Clearly there are issues if this is on some block device that hasn't been resumed yet. > BTW, I know of two subsystems that want their kernel threads to be frozen for > synchronization purposes. Please see these messages: > > 1) https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012592.html > (plus follow up) > > 2) http://marc.info/?l=linux-kernel&m=117919066830575&w=2 I'm not entirely sold on this. The issue is that there's the possibility of races during suspend/resume? It sounds like that should be implemented in the driver, rather than depending on a side-effect of process freezing. Otherwise there's no way of selectively suspending that device. > Besides, there's the hibernation that needs to freeze tasks for another reason, > so it needs some way to ensure that drivers won't request firmware while > the user land is frozen. I agree that that's an issue right now, but I think we should see if this is repairable without just breaking those drivers. One option would be to defer resuming them until userspace is alive again - that would be no worse than the suspend to RAM case without process freezing. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
