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

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

On Mon, 2014-03-10 at 21:47 -0700, Dan Williams wrote:
> On Mon, Mar 10, 2014 at 9:19 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 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.
> >
> 
> In that case shouldn't we limit it to a disk at a time?  Enterprise
> doesn't care and home brew folks that both put a lot of disks in a
> system and suspend/resume them are less likely to burn themselves.

Where do you get that idea from?  the enterprise is amazingly sensitive
to system start times; they'd demand my head on a plate if we started a
disk at a time and their start times went up by 10x.  That's why we
leave it to hard wiring ... they can start in batches the maximum number
allowable and thus get the shortest start up times.

In the long game, though this whole debate is moot: setups with hard
wired start times adhere to them regardless of what the system does, so
they ignore start unit commands.  Systems without hard wired start times
can usually be started at once, so us introducing a delay is unnecessary
in either case.

James