Re: [PATCH v5 3/3] scsi: async sd resume

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2014-03-10 at 16:59 -0400, Alan Stern wrote:
> On Mon, 10 Mar 2014, Dan Williams wrote:
> 
> > > The only thing which is a bit concerning is that this doesn't have any
> > > throttling mechanism for simultaneous wakeups.  Would this be able to
> > > blow up the PSU if used on a machine with a lot of spindles?
> > 
> > Good point.  The primary benefit is completing userspace resume
> > without needlessly waiting for the disk.  For now I think it would be
> > enough to have a mutex to maintain one disk at a time.  We can follow
> > on later with something more complex to enable a max simultaneous
> > spin-up tunable.
> 
> Why?  The existing code doesn't have anything like that.

This only becomes a problem if enterprise class systems want to suspend
and resume.  Last I heard, this wasn't on the cards.

We also don't usually need to bother with in-kernel staggered spin ups
because if the device can blow the PSU by doing simultaneous spinups,
staggering is usually hard jumpered in the system.  The main reason for
this is that there's no way for us to work out the PSU topology to do
the stagger in kernel, so the enterprise likes to be sure.

James