On Mon, Mar 10, 2014 at 10:16 PM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > 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. Just considering the dpm_resume path, not device discovery... > 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. Ok, then I'll let the patch stand as is. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
