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