Re: Nested suspends; messages vs. states

Patrick Mochel
2005-03-24T17:51:47Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1235 bytes --]

On Thu, 24 Mar 2005, Patrick Mochel wrote:

>
> On Thu, 24 Mar 2005, Alan Stern wrote:
>
> > On Wed, 23 Mar 2005, Patrick Mochel wrote:
>
> > > It would make it potentially very hard to debug and add a lot of
> > > time to the process.
> >
> > Hard to debug, maybe... we can't tell without actually trying. Adding a
> > lot of time to the suspend process, no. Acquiring the locks would block
> > only for things that should cause you to block anyway, like trying to
> > suspend a device while it's being probed.
>
> It would change the locking from an O(1) operation to an O(n) operation,
> where n is the number of devices. Taking any lock is not cheap, so taking
> N locks, when is N is large is going to be grossly inefficient.

Ok, I'm a hypocrit. :)

The first patch in the series that I posted adds a semaphore to struct
device that is taken before each driver operation, including suspend and
resume. It is dropped, though, when the operation is complete. I think
that's the right way to do it, and I'm interested to hear if that will
work for what you guys want to do.

I *do* realize that it is equivalent in terms of time spent acquiring and
releasing locks that I bashed above. I will eat my words now.

Thanks,

Pat