Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)
in [Kernel]
|
Prev: futex: Take mmap_sem for get_user_pages in fault_in_user_writeable
Next: [PATCH v9 0/8] Loongson: YeeLoong: add platform drivers
From: Linus Torvalds on 9 Dec 2009 10:40 On Wed, 9 Dec 2009, Alan Stern wrote: > > In fact these considerations already affect the USB resume operations, > even without asynchronous resume. The code relies on the fact that the > PCI layer registers sibling devices on a slot in order of increasing > function number. There's no guarantee this will remain true in the > future (it may already be wrong AFAIK), so putting in some explicit > list manipulation is the prudent thing to do. I do think we want to keep the slot ordering. One of the silent issues that the device management code has always had is the whole notion of naming stability. Now, udev and various fancy naming schemes solve that at a higher level, but it is still the case that we _really_ want basic things like your PCI controllers to show up in stable order. For example, it is _very_ inconvenient if things like PCI probing ends up allocating different bus numbers (or resource allocations) across reboots even if the hardware hasn't been changed. Just from a debuggability standpoint, that just ends up being a total disaster. For example, we continually hit odd special cases where PCI resource allocation has some unexplained problem because there is some motherboard resource that is hidden and invisible to our allocator. They are rare in the sense that it's usually just a couple of odd laptops or something, but they are not rare in the sense that pretty much _every_ single time we change some resource allocation logic, we find one or two machines that have some issue. Things like that would be total disasters if the core device layer then ended up also not having well-defined ordering. This is why I don't want to do asynchronous PCI device probing, for example (ie we probe the hardware synchronously, the PCI driver sets it all up synchronously, and the asynchronous portion is the non-PCI part if any - things like PHY detection, disk spinup etc). So async things are fine, but they have _huge_ disadvantages, and I'll personally take reliability and a stable serial algorithm over an async one as far as possible. That's partly why I realy did suggest that we do the async stuff purely in the USB layer, rather than try to put it deeper in the device layer. And if we do support it "natively" in the device layer like Rafael's latest patch, I still think we should be very very nervous about making devices async unless there is a measured - and very noticeable - advantage. So I really don't want to push things any further than absolutely necessary. I do not think that something like "embedded audio" is a reason for async, for example. Linus -- 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: Alan Stern on 9 Dec 2009 11:00 On Wed, 9 Dec 2009, Linus Torvalds wrote: > That's partly why I realy did suggest that we do the async stuff purely in > the USB layer, rather than try to put it deeper in the device layer. And > if we do support it "natively" in the device layer like Rafael's latest > patch, I still think we should be very very nervous about making devices > async unless there is a measured - and very noticeable - advantage. Agreed. Arjan's measurements indicated that USB was one of the biggest offenders; everything else other than the PS/2 mouse was much faster. Given these results there isn't much incentive to do anything else asynchronously. (However other devices not present on Arjan's machine may be a different story. Spinning up multiple external disks is a good example -- although here it may be necessary for the driver to take charge, because spinning up a disk requires a lot of power and doing too many of them at the same time could be bad.) Alan Stern -- 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: Alan Stern on 9 Dec 2009 11:00 On Wed, 9 Dec 2009, Mark Brown wrote: > On Tue, Dec 08, 2009 at 09:35:59PM -0500, Alan Stern wrote: > > On Tue, 8 Dec 2009, Linus Torvalds wrote: > > > > It's just that I think the "looping over children" is ugly, when I think > > > that by doing it the other way around you can make the code simpler and > > > only depend on the PM device list and a simple parent pointer access. > > > I agree that it is uglier. The only advantage is in handling > > asynchronous non-tree suspend dependencies, of which we probably won't > > have very many. In fact, I don't know of _any_ offhand. > > There's some potential for this in embedded audio - it wants to bring > down the entire embedded audio subsystem at once before the individual > devices (and their parents) get suspended since bringing them down out > of sync can result in audible artifacts. Depending on the system the > suspend may take a noticable amount of time so it'd be nice to be able > to run it asynchronously, though we don't currently do so. For something like bringing down the entire embedded audio subsystem, which isn't directly tied to a single device, you would probably be better off doing it when the PM core broadcasts a suspend notification (see register_pm_notifier() in include/linux/suspend.h). This occurs before any devices are suspended, so synchronization isn't an issue. > At the minute we get away with this mostly through not being able to > represent the cases that are likely to actually trip up over it. > > > Interestingly, this non-tree dependency problem does not affect resume. > > Embedded audio does potentially - the resume needs all the individual > devices in the subsystem and can take a substantial proportion of the > overall resume time. Currently we get away with a combination of > assuming that all the drivers are live when we decide to start resuming > them and using the ALSA userspace API to deal with bringing the resume > out of line, but it's not ideal. You can do the same thing with the resume notifier. Alan Stern -- 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: Mark Brown on 9 Dec 2009 11:10 On Wed, Dec 09, 2009 at 10:49:56AM -0500, Alan Stern wrote: > On Wed, 9 Dec 2009, Mark Brown wrote: > > There's some potential for this in embedded audio - it wants to bring > > down the entire embedded audio subsystem at once before the individual > > devices (and their parents) get suspended since bringing them down out > For something like bringing down the entire embedded audio subsystem, > which isn't directly tied to a single device, you would probably be > better off doing it when the PM core broadcasts a suspend notification > (see register_pm_notifier() in include/linux/suspend.h). This occurs > before any devices are suspended, so synchronization isn't an issue. I'm not convinced that helps with the fact that the suspend may take a long time - ideally we'd be able to start the suspend process off but let other things carry on while it completes without having to worry about something we're relying on getting suspended underneath us. > > Embedded audio does potentially - the resume needs all the individual > > overall resume time. Currently we get away with a combination of > You can do the same thing with the resume notifier. Similarly, the length of time the resume may take to complete means it'd be nice to start as soon as we've got the devices and complete it at our leisure. This is less pressing since we can tell the PM core we've resumed but still block userspace. -- 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: Alan Stern on 9 Dec 2009 11:30
On Wed, 9 Dec 2009, Mark Brown wrote: > On Wed, Dec 09, 2009 at 10:49:56AM -0500, Alan Stern wrote: > > On Wed, 9 Dec 2009, Mark Brown wrote: > > > > There's some potential for this in embedded audio - it wants to bring > > > down the entire embedded audio subsystem at once before the individual > > > devices (and their parents) get suspended since bringing them down out > > > For something like bringing down the entire embedded audio subsystem, > > which isn't directly tied to a single device, you would probably be > > better off doing it when the PM core broadcasts a suspend notification > > (see register_pm_notifier() in include/linux/suspend.h). This occurs > > before any devices are suspended, so synchronization isn't an issue. > > I'm not convinced that helps with the fact that the suspend may take a > long time - ideally we'd be able to start the suspend process off but > let other things carry on while it completes without having to worry > about something we're relying on getting suspended underneath us. The suspend procedure is oriented around device structures, and what you're talking about isn't. It's something separate which has to be finished before _any_ of the audio devices are suspended. How long does it take to bring down the entire embedded audio subsystem? And how critical is the timing for typical systems? Alan Stern -- 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/ |