Async suspend-resume patch w/ completions (was: Re: Async suspend-resume patch w/ rwsems)
in [Kernel]
|
Prev: [PATCH 3/4] ftrace - add fdd script
Next: drivers/media/video/uvc: Correct size given to memset
From: Rafael J. Wysocki on 20 Dec 2009 08:00 On Sunday 20 December 2009, Alan Stern wrote: > On Sat, 19 Dec 2009, Rafael J. Wysocki wrote: > > > On Friday 18 December 2009, Alan Stern wrote: > > > On Fri, 18 Dec 2009, Rafael J. Wysocki wrote: > > > > > > > I didn't manage to do that, but I was able to mark sd and i8042 as async and > > > > see the impact of this. > > > > > > Apparently this didn't do what you wanted. In the nx6325 > > > sd+i8042+async+extra log, the 0:0:0:0 device (which is a SCSI disk) was > > To be precise, the device is an ATA or SATA disk but it is managed by > the sd driver. > > > > suspended by the main thread instead of an async thread. > > > > Hm, that's odd, because there's a noticeable time difference between the > > two cases in which the sd is sync and async. I'll look into it further. > > I don't know what the whole story is, but the PID number tells the > tale. > > > > There's an important point I neglected to mention before. Your logs > > > don't show anything for devices with no suspend callbacks at all. > > > Nevertheless, these devices sit on the device list and prevent other > > > devices from suspending or resuming as soon as they could. > > > > Unless they are async, that is. > > Yes. It would be simpler to make them async. But first we ought to > know what they are. Can you add an extra line to the log for such > devices? Sure, I'll do that. > What I'm afraid of is that there might be a "normal" device with a > "normal" ancestor but with "abnormal" devices in between (where > "normal" means there is a suspend or resume routine and "abnormal" > means all the method pointers are NULL). I know that this happens when > there's a USB mass-storage device, for example. If we complete the > intermediate devices immediately, then there won't be anything to > prevent the ancestor from suspending before the device or the device > from resuming before the ancestor. I'm afraid of that too. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 20 Dec 2009 08:00 On Sunday 20 December 2009, Alan Stern wrote: > On Sun, 20 Dec 2009, Rafael J. Wysocki wrote: > > > So, seriously, do you think it makes sense to do asynchronous suspend at all? > > I'm asking, because we're likely to get into troubles like this during suspend > > for other kinds of devices too and without resolving them we won't get any > > significant speedup from asynchronous suspend. > > > > That said, to me it's definitely worth doing asynchronous resume with the > > "start asynch threads upfront" modification, as the results of the tests show > > that quite clearly. I hope you agree. > > It's too early to come to this sort of conclusion (i.e., that suspend > and resume react very differently to an asynchronous approach). Unless > you have some definite _reason_ for thinking that resume will benefit > more than suspend, you shouldn't try to generalize so much from tests > on only two systems. In fact I have one reason. Namely, the things that drivers do on suspend and resume are evidently quite different and on these two systems I was able to test they apparently took different amounts of time to complete. The very fact that on both systems resume is substantially longer than suspend, even if all devices are suspended and resumed synchronously, is quite interesting. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 20 Dec 2009 13:20 On Sunday 20 December 2009, Alan Stern wrote: > On Sun, 20 Dec 2009, Rafael J. Wysocki wrote: > > > > It's too early to come to this sort of conclusion (i.e., that suspend > > > and resume react very differently to an asynchronous approach). Unless > > > you have some definite _reason_ for thinking that resume will benefit > > > more than suspend, you shouldn't try to generalize so much from tests > > > on only two systems. > > > > In fact I have one reason. Namely, the things that drivers do on suspend and > > resume are evidently quite different and on these two systems I was able to > > test they apparently took different amounts of time to complete. > > > > The very fact that on both systems resume is substantially longer than suspend, > > even if all devices are suspended and resumed synchronously, is quite > > interesting. > > Yes, it is. But it doesn't mean that suspend won't benefit from > asynchronicity; it just means that the benefits might not be as large > as they are for resume. Agreed, although that rises the question whether they are sufficiently significant. I guess time will tell. With the i8042 done asynchronously they are IMO. BTW, what's the right place to call device_enable_async_suspend() for USB devices? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 20 Dec 2009 15:00
On Sunday 20 December 2009, Alan Stern wrote: > On Sun, 20 Dec 2009, Rafael J. Wysocki wrote: > > > BTW, what's the right place to call device_enable_async_suspend() for USB > > devices? > > For USB devices, it's in drivers/usb/core/hub.c:usb_new_device() > anywhere before the call to usb_device_add(). > > For USB interfaces, it's in > drivers/usb/core/message.c:usb_set_configuration() before the call to > device_add(). > > For USB endpoints, it's in > drivers/usb/core/endpoint.c:usb_create_ep_devs() before the call to > device_register(). Thanks! > However you won't need to do it for interfaces and endpoints if you > automatically treat as async any device without suspend/resume > callbacks. I don't do that right now and I need these settings just for testing at the moment. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |