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: Alan Stern on 9 Dec 2009 17:30 On Wed, 9 Dec 2009, Rafael J. Wysocki wrote: > > I don't like that because it introduces "artificial" dependencies: It > > makes B depend on all the preceding synchronous suspends, even totally > > unrelated ones. But yes, it would work. > > Well, unfortunately, it wouldn't, because (at least in the context of my last > patch) the core would release the rwsems as soon as your suspend had > returned. So you'd have to make your suspend wait for the async thread and > that would make it pointless. So scratch that, it wasn't a good idea at all. > > This leaves us with basically two options, where the first one is to use > rwsems in a way that you've proposed (with iterating over children), and the > second one is to use completions. In my opinion rwsems don't give us any > advantage in this case, so I'd very much prefer to use completions. If you really want to add support for async suspend constraints, then completions are clearer than rwsems. If you don't care (and it's unlikely that anyone will need them in the near future) then you might as well stick with the current rwsem implementation and avoid iterating over children. 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: Pavel Machek on 25 Dec 2009 12:20
Hi! > > 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.) Well, system would better be able to supply enough current... because usb disks auto-sleep on their own, and then something like async ls -l /*/* would kill your machine... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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/ |