Re: No freezing of kernel threads (was: Re: [GIT PULL] libata fixesfor v3.13-rc5)
From: Tejun Heo
Date: Thu Dec 26 2013 - 14:01:40 EST
On Thu, Dec 26, 2013 at 01:42:29PM -0500, Alan Stern wrote:
> In the case of hibernation, it's not so simple. We do need to perform
> I/O, in order to save the memory image. But we also need to avoid
> unnecessary I/O, in order to keep the on-disk data consistent with the
> data in the memory image. You probably can't accomplish this at the
> device driver or subsystem level.
That was what I assumed too but Rafael tells me it has nothing to do
> > which bothers me about the freezer is that it's essentially a separate
> > entry point for suspend/resume implementation, and not a particularly
> > well designed one at that. Things which depend on freezer for PM ops
> > would need completely separate paths for runtime PM. They probably
> > need some deviations anyway but freezer would push it unnecessarily.
> Maybe it's the other way around: The separate paths are necessary, and
> the freezer _simplifies_ the system sleep ops.
Again, the point is it's too big a tool given the problem with history
of abuse. It sure is "convenient" to have tools at that level for
that particular user - not because the task at hand fits such solution
but because a lot more is being paid elsewhere. It just is out of
proportion and isn't a good design in larger sense.
As for autopm vs. system pm, there sure are necessary differences
between the two but they also can share a lot. At least, it looks
that way from libata side. I really don't think having two separate
paradigms in implementing PM is a good idea even if the two paths have
to deviate in significant ways.
> Taking khubd as an example, I have to agree that converting it to a
> workqueue would be a big simplification overall. And yet there are
> some things khubd does which are (as far as I know) rather difficult to
> accomplish with workqueues. One example in drivers/usb/core/hub.c:
> kick_khubd() calls usb_autopm_get_interface_no_resume() if and only if
> it added the hub to the event list (and it does so before releasing the
> list's lock). How can you do that with a workqueue?
Do the same thing and just replace wake_up() with queue_work()?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/