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 -- 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
