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@xxxxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
