* Re: Stop SSD from waiting for "Spinning up disk..." @ 2015-06-23 18:26 Andreas Mohr 2015-06-23 18:55 ` Martin Steigerwald 0 siblings, 1 reply; 15+ messages in thread From: Andreas Mohr @ 2015-06-23 18:26 UTC (permalink / raw) To: Jeff Chua; +Cc: Greg Kroah-Hartman, linux-kernel, Christoph Hellwig Hi, [proper In-Reply-To trail missing since lkml.org now fails to provide it] > On Mon, Jun 22, 2015 at 11:36 PM, Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Jun 22, 2015 at 03:25:29PM +0800, Jeff Chua wrote: > >> > >> There's no need to wait for disk spin-up for USB SSD devices. This > >> patch > >> allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 > >> during > >> boot-up. > >> > >> If there's a better way to handle this, please share. > > > > Module parameters are never a solution for a device-specific property, > > sorry. This statement, while somewhat harsh, seems about correct, from a data attribute structure/organization POV. > > Greg, > > SSD is coming mainstream and it doesn't make sense wasting time > spinning up "disk" ... ...which probably is not truly being achieved by providing a *custom* kernel parameter which does apply to only those disk instances which some users *specifically* care about. Some things come to mind: - at this scope, generally spoken one shouldn't be concerned with whether "we are SSD", but rather whether "we (do not) need spinup" (which might apply to a ton of different SCSI-based storage devices, even some SAN-based platter-based ones) *This* is what this is about (and this could then have been reflected in kernel parameter naming) - AFAIR SCSI mode info pages might contain hints as to whether a disk is "rotating" (but possibly these are not fully reliably accessible pre-spinup, and mode info page content probably is unreliable, too) - projects such as smartmontools might be able to provide some hints as to how to reliably detect *certain* non-rotating types (i.e., SSD) - the kernel must already have some mechanisms to discern between (non-)platters (e.g. perhaps for knowing whether to support SSD TRIM command) - if we want to avoid doing spinup handling (I guess we do), then that handling should be implemented *within* the function that is doing that (sd_spinup_disk(), or perhaps an outer wrapper of it, sd_try_spinup_disk()) rather than at one specific callsite of that function only (think sd_spinup_disk() *will* be allowed to "pretend" a "success" result for all storage types which simply do not need spinup) - finally, it might be questionable *why* (whether) at certain points we currently need (decide) to do spinup requests - I guess it's in order to ensure in advance that the disk will be ready once it actually will be needed, or so Thank you very much for having come up with this issue & HTH, Andreas Mohr ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Stop SSD from waiting for "Spinning up disk..." 2015-06-23 18:26 Stop SSD from waiting for "Spinning up disk..." Andreas Mohr @ 2015-06-23 18:55 ` Martin Steigerwald 2015-06-24 16:22 ` Jeff Chua 0 siblings, 1 reply; 15+ messages in thread From: Martin Steigerwald @ 2015-06-23 18:55 UTC (permalink / raw) To: Andreas Mohr Cc: Jeff Chua, Greg Kroah-Hartman, linux-kernel, Christoph Hellwig Am Dienstag, 23. Juni 2015, 20:26:12 schriebst Du: > Hi, Hi, > [proper In-Reply-To trail missing since lkml.org now fails to provide it] […] > > Greg, > > > > SSD is coming mainstream and it doesn't make sense wasting time > > spinning up "disk" ... > > ...which probably is not truly being achieved > by providing a *custom* kernel parameter > which does apply to only those disk instances > which some users *specifically* care about. > > Some things come to mind: > > - at this scope, generally spoken > one shouldn't be concerned with whether "we are SSD", > but rather whether "we (do not) need spinup" > (which might apply to a ton of different SCSI-based storage devices, > even some SAN-based platter-based ones) > *This* is what this is about > (and this could then have been reflected in kernel parameter naming) […] > - the kernel must already have some mechanisms to discern between > (non-)platters (e.g. perhaps for knowing whether to support SSD TRIM > command) Yep, for the first SSD in this laptop: merkaba:/sys> cat ./devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda/queue/rotational 0 […] Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Stop SSD from waiting for "Spinning up disk..." 2015-06-23 18:55 ` Martin Steigerwald @ 2015-06-24 16:22 ` Jeff Chua 2015-06-24 16:28 ` Greg Kroah-Hartman 0 siblings, 1 reply; 15+ messages in thread From: Jeff Chua @ 2015-06-24 16:22 UTC (permalink / raw) To: Martin Steigerwald Cc: Andreas Mohr, Greg Kroah-Hartman, lkml, Christoph Hellwig On Wed, Jun 24, 2015 at 2:55 AM, Martin Steigerwald <martin@lichtvoll.de> wrote: > Am Dienstag, 23. Juni 2015, 20:26:12 schriebst Du: >> Hi, > > Hi, > >> [proper In-Reply-To trail missing since lkml.org now fails to provide it] > […] >> > Greg, >> > >> > SSD is coming mainstream and it doesn't make sense wasting time >> > spinning up "disk" ... >> >> ...which probably is not truly being achieved >> by providing a *custom* kernel parameter >> which does apply to only those disk instances >> which some users *specifically* care about. >> >> Some things come to mind: >> >> - at this scope, generally spoken >> one shouldn't be concerned with whether "we are SSD", >> but rather whether "we (do not) need spinup" >> (which might apply to a ton of different SCSI-based storage devices, >> even some SAN-based platter-based ones) >> *This* is what this is about >> (and this could then have been reflected in kernel parameter naming) > […] >> - the kernel must already have some mechanisms to discern between >> (non-)platters (e.g. perhaps for knowing whether to support SSD TRIM >> command) > > Yep, for the first SSD in this laptop: > > merkaba:/sys> cat > ./devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda/queue/rotational > 0 It seems "rotational" is not reporting the correct status on USB devices ... # cat /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/queue/rotational 0 # cat sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/block/sdb/queue/rotational 1 # dmesg scsi host11: uas scsi 10:0:0:0: Direct-Access JMicron Generic 0114 PQ: 0 ANSI: 6 # cat /sys/kernel/debug/usb/devices T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=152d ProdID=0567 Rev= 1.14 S: Manufacturer=JMicron S: Product=USB to ATA/ATAPI Bridge S: SerialNumber=3186E514500030 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 8mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=uas Both sda and sdb have the same SSD model. Jeff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Stop SSD from waiting for "Spinning up disk..." 2015-06-24 16:22 ` Jeff Chua @ 2015-06-24 16:28 ` Greg Kroah-Hartman 2015-06-24 23:55 ` Jeff Chua 0 siblings, 1 reply; 15+ messages in thread From: Greg Kroah-Hartman @ 2015-06-24 16:28 UTC (permalink / raw) To: Jeff Chua; +Cc: Martin Steigerwald, Andreas Mohr, lkml, Christoph Hellwig On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote: > On Wed, Jun 24, 2015 at 2:55 AM, Martin Steigerwald <martin@lichtvoll.de> wrote: > > Am Dienstag, 23. Juni 2015, 20:26:12 schriebst Du: > >> Hi, > > > > Hi, > > > >> [proper In-Reply-To trail missing since lkml.org now fails to provide it] > > […] > >> > Greg, > >> > > >> > SSD is coming mainstream and it doesn't make sense wasting time > >> > spinning up "disk" ... > >> > >> ...which probably is not truly being achieved > >> by providing a *custom* kernel parameter > >> which does apply to only those disk instances > >> which some users *specifically* care about. > >> > >> Some things come to mind: > >> > >> - at this scope, generally spoken > >> one shouldn't be concerned with whether "we are SSD", > >> but rather whether "we (do not) need spinup" > >> (which might apply to a ton of different SCSI-based storage devices, > >> even some SAN-based platter-based ones) > >> *This* is what this is about > >> (and this could then have been reflected in kernel parameter naming) > > […] > >> - the kernel must already have some mechanisms to discern between > >> (non-)platters (e.g. perhaps for knowing whether to support SSD TRIM > >> command) > > > > Yep, for the first SSD in this laptop: > > > > merkaba:/sys> cat > > ./devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda/queue/rotational > > 0 > > > It seems "rotational" is not reporting the correct status on USB devices ... > > # cat /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/queue/rotational > 0 > # cat sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/block/sdb/queue/rotational > 1 > > # dmesg > scsi host11: uas > scsi 10:0:0:0: Direct-Access JMicron Generic 0114 PQ: 0 ANSI: 6 > > # cat /sys/kernel/debug/usb/devices > T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 > D: Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 > P: Vendor=152d ProdID=0567 Rev= 1.14 > S: Manufacturer=JMicron > S: Product=USB to ATA/ATAPI Bridge > S: SerialNumber=3186E514500030 > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 8mA > I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=uas > > > Both sda and sdb have the same SSD model. That's a bug in your USB bridge chip, odds are it is not reporting the value properly. There's nothing the scsi core or USB stack can do about this, sorry. Please complain to the hardware manufacturer. greg k-h ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Stop SSD from waiting for "Spinning up disk..." 2015-06-24 16:28 ` Greg Kroah-Hartman @ 2015-06-24 23:55 ` Jeff Chua 2015-06-25 1:41 ` Greg Kroah-Hartman 0 siblings, 1 reply; 15+ messages in thread From: Jeff Chua @ 2015-06-24 23:55 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Martin Steigerwald, Andreas Mohr, lkml, Christoph Hellwig On Thu, Jun 25, 2015 at 12:28 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote: >> Both sda and sdb have the same SSD model. > > That's a bug in your USB bridge chip, odds are it is not reporting the > value properly. There's nothing the scsi core or USB stack can do about > this, sorry. Please complain to the hardware manufacturer. There are workaround boot cmdline parameters for other things ... any chance to consider one to fix broken rotational option? I'm not sure how many out there are broken, but I really would like a faster way to access my USB SSD without waiting for the "disk spinup". Thanks, Jeff. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Stop SSD from waiting for "Spinning up disk..." 2015-06-24 23:55 ` Jeff Chua @ 2015-06-25 1:41 ` Greg Kroah-Hartman 2015-06-25 6:08 ` Martin Steigerwald 0 siblings, 1 reply; 15+ messages in thread From: Greg Kroah-Hartman @ 2015-06-25 1:41 UTC (permalink / raw) To: Jeff Chua; +Cc: Martin Steigerwald, Andreas Mohr, lkml, Christoph Hellwig On Thu, Jun 25, 2015 at 07:55:45AM +0800, Jeff Chua wrote: > On Thu, Jun 25, 2015 at 12:28 AM, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote: > > >> Both sda and sdb have the same SSD model. > > > > That's a bug in your USB bridge chip, odds are it is not reporting the > > value properly. There's nothing the scsi core or USB stack can do about > > this, sorry. Please complain to the hardware manufacturer. > > There are workaround boot cmdline parameters for other things ... any > chance to consider one to fix broken rotational option? I'm not sure > how many out there are broken, but I really would like a faster way to > access my USB SSD without waiting for the "disk spinup". Just like module paramaters, boot command lines are not for device specific attributes, sorry. Again, please contact the manufacturer to get this fixed. We can't add a quirk for this bridge because it would not work if you really put a rotational disk behind it. Given the cheap cost of these types of bridges, I recommend just getting one that works. Best of luck, greg k-h ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Stop SSD from waiting for "Spinning up disk..." 2015-06-25 1:41 ` Greg Kroah-Hartman @ 2015-06-25 6:08 ` Martin Steigerwald 2015-06-25 8:52 ` Jeff Chua 0 siblings, 1 reply; 15+ messages in thread From: Martin Steigerwald @ 2015-06-25 6:08 UTC (permalink / raw) To: Greg Kroah-Hartman; +Cc: Jeff Chua, Andreas Mohr, lkml, Christoph Hellwig Am Mittwoch, 24. Juni 2015, 18:41:52 schrieb Greg Kroah-Hartman: > On Thu, Jun 25, 2015 at 07:55:45AM +0800, Jeff Chua wrote: > > On Thu, Jun 25, 2015 at 12:28 AM, Greg Kroah-Hartman > > > > <gregkh@linuxfoundation.org> wrote: > > > On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote: > > >> Both sda and sdb have the same SSD model. > > > > > > That's a bug in your USB bridge chip, odds are it is not reporting the > > > value properly. There's nothing the scsi core or USB stack can do > > > about > > > this, sorry. Please complain to the hardware manufacturer. > > > > There are workaround boot cmdline parameters for other things ... any > > chance to consider one to fix broken rotational option? I'm not sure > > how many out there are broken, but I really would like a faster way to > > access my USB SSD without waiting for the "disk spinup". > > Just like module paramaters, boot command lines are not for device > specific attributes, sorry. Again, please contact the manufacturer to > get this fixed. We can't add a quirk for this bridge because it would > not work if you really put a rotational disk behind it. How about a way to override it in sysfs directly during runtime just for a device individually, like choosing an I/O scheduler for example? > Given the cheap cost of these types of bridges, I recommend just getting > one that works. That is an option as well and may educate hardware manufacturers to look a bit better at the quality of those devices (at least then Linux market share in that market increases). Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Stop SSD from waiting for "Spinning up disk..." 2015-06-25 6:08 ` Martin Steigerwald @ 2015-06-25 8:52 ` Jeff Chua 0 siblings, 0 replies; 15+ messages in thread From: Jeff Chua @ 2015-06-25 8:52 UTC (permalink / raw) To: Martin Steigerwald Cc: Greg Kroah-Hartman, Andreas Mohr, lkml, Christoph Hellwig On Thu, Jun 25, 2015 at 2:08 PM, Martin Steigerwald <martin@lichtvoll.de> wrote: > Am Mittwoch, 24. Juni 2015, 18:41:52 schrieb Greg Kroah-Hartman: >> On Thu, Jun 25, 2015 at 07:55:45AM +0800, Jeff Chua wrote: >> > On Thu, Jun 25, 2015 at 12:28 AM, Greg Kroah-Hartman >> > >> > <gregkh@linuxfoundation.org> wrote: >> > > On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote: >> > >> Both sda and sdb have the same SSD model. >> > > >> > > That's a bug in your USB bridge chip, odds are it is not reporting the >> > > value properly. There's nothing the scsi core or USB stack can do >> > > about >> > > this, sorry. Please complain to the hardware manufacturer. >> > >> > There are workaround boot cmdline parameters for other things ... any >> > chance to consider one to fix broken rotational option? I'm not sure >> > how many out there are broken, but I really would like a faster way to >> > access my USB SSD without waiting for the "disk spinup". >> >> Just like module paramaters, boot command lines are not for device >> specific attributes, sorry. Again, please contact the manufacturer to >> get this fixed. We can't add a quirk for this bridge because it would >> not work if you really put a rotational disk behind it. > > How about a way to override it in sysfs directly during runtime just for a > device individually, like choosing an I/O scheduler for example? > >> Given the cheap cost of these types of bridges, I recommend just getting >> one that works. > > That is an option as well and may educate hardware manufacturers to look a > bit better at the quality of those devices (at least then Linux market share > in that market increases). I just needed something. "throwing" those cheap USB3 ... like I've a bunch of them. It's just a waste... and they are perfectly fast "uas" interfaces! Thanks, Jeff. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Stop SSD from waiting for "Spinning up disk..." @ 2015-06-22 7:25 Jeff Chua 2015-06-22 15:36 ` Greg Kroah-Hartman 2015-06-25 16:21 ` Henrique de Moraes Holschuh 0 siblings, 2 replies; 15+ messages in thread From: Jeff Chua @ 2015-06-22 7:25 UTC (permalink / raw) To: Linux Kernel; +Cc: Christoph Hellwig, Greg Kroah-Hartman There's no need to wait for disk spin-up for USB SSD devices. This patch allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 during boot-up. If there's a better way to handle this, please share. Thanks, Jeff --- linux/drivers/scsi/sd.c 2015-05-25 07:29:44.000000000 +0800 +++ linux/drivers/scsi/sd.c 2015-06-19 22:17:35.000000000 +0800 @@ -92,6 +92,9 @@ MODULE_ALIAS_SCSI_DEVICE(TYPE_MOD); MODULE_ALIAS_SCSI_DEVICE(TYPE_RBC); +static int ssd = 0; +module_param(ssd, int, 0); + #if !defined(CONFIG_DEBUG_BLOCK_EXT_DEVT) #define SD_MINORS 16 #else @@ -2738,7 +2741,9 @@ goto out; } - sd_spinup_disk(sdkp); + sd_printk(KERN_NOTICE, sdkp, "ssd %s\n", ssd == 0 ? "off" : "on"); + if(!ssd) + sd_spinup_disk(sdkp); /* * Without media there is no reason to ask; moreover, some devices -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Stop SSD from waiting for "Spinning up disk..." 2015-06-22 7:25 Jeff Chua @ 2015-06-22 15:36 ` Greg Kroah-Hartman 2015-06-23 15:02 ` Jeff Chua 2015-06-25 16:21 ` Henrique de Moraes Holschuh 1 sibling, 1 reply; 15+ messages in thread From: Greg Kroah-Hartman @ 2015-06-22 15:36 UTC (permalink / raw) To: Jeff Chua; +Cc: Linux Kernel, Christoph Hellwig On Mon, Jun 22, 2015 at 03:25:29PM +0800, Jeff Chua wrote: > > There's no need to wait for disk spin-up for USB SSD devices. This patch > allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 during > boot-up. > > If there's a better way to handle this, please share. Module parameters are never a solution for a device-specific property, sorry. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Stop SSD from waiting for "Spinning up disk..." 2015-06-22 15:36 ` Greg Kroah-Hartman @ 2015-06-23 15:02 ` Jeff Chua 2015-06-23 18:27 ` Frans Klaver 2015-06-23 18:51 ` Marc Burkhardt 0 siblings, 2 replies; 15+ messages in thread From: Jeff Chua @ 2015-06-23 15:02 UTC (permalink / raw) To: Greg Kroah-Hartman; +Cc: Linux Kernel, Christoph Hellwig On Mon, Jun 22, 2015 at 11:36 PM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Mon, Jun 22, 2015 at 03:25:29PM +0800, Jeff Chua wrote: >> >> There's no need to wait for disk spin-up for USB SSD devices. This patch >> allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 during >> boot-up. >> >> If there's a better way to handle this, please share. > > Module parameters are never a solution for a device-specific property, > sorry. Greg, SSD is coming mainstream and it doesn't make sense wasting time spinning up "disk" ... Jeff. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Stop SSD from waiting for "Spinning up disk..." 2015-06-23 15:02 ` Jeff Chua @ 2015-06-23 18:27 ` Frans Klaver 2015-06-23 18:51 ` Marc Burkhardt 1 sibling, 0 replies; 15+ messages in thread From: Frans Klaver @ 2015-06-23 18:27 UTC (permalink / raw) To: Jeff Chua; +Cc: Greg Kroah-Hartman, Linux Kernel, Christoph Hellwig On Tue, Jun 23, 2015 at 5:02 PM, Jeff Chua <jeff.chua.linux@gmail.com> wrote: > On Mon, Jun 22, 2015 at 11:36 PM, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: >> On Mon, Jun 22, 2015 at 03:25:29PM +0800, Jeff Chua wrote: >>> >>> There's no need to wait for disk spin-up for USB SSD devices. This patch >>> allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 during >>> boot-up. >>> >>> If there's a better way to handle this, please share. >> >> Module parameters are never a solution for a device-specific property, >> sorry. > > Greg, > > SSD is coming mainstream and it doesn't make sense wasting time > spinning up "disk" ... I don't think Greg disputes that. He just objects to the solution (a module parameter) you proposed. I'd guess that detecting that we're talking to an SSD and then skipping the wait would make more sense, if at all possible. Frans ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Stop SSD from waiting for "Spinning up disk..." 2015-06-23 15:02 ` Jeff Chua 2015-06-23 18:27 ` Frans Klaver @ 2015-06-23 18:51 ` Marc Burkhardt 1 sibling, 0 replies; 15+ messages in thread From: Marc Burkhardt @ 2015-06-23 18:51 UTC (permalink / raw) To: Jeff Chua, Greg Kroah-Hartman; +Cc: Linux Kernel, Christoph Hellwig You might want to grep for QUEUE_FLAG_NONROT or queue_nonrot_entry... Regards, Marc P.S: sent from mobile, might be short. Am 23. Juni 2015 17:02:22 MESZ, schrieb Jeff Chua <jeff.chua.linux@gmail.com>: >On Mon, Jun 22, 2015 at 11:36 PM, Greg Kroah-Hartman ><gregkh@linuxfoundation.org> wrote: >> On Mon, Jun 22, 2015 at 03:25:29PM +0800, Jeff Chua wrote: >>> >>> There's no need to wait for disk spin-up for USB SSD devices. This >patch >>> allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 >during >>> boot-up. >>> >>> If there's a better way to handle this, please share. >> >> Module parameters are never a solution for a device-specific >property, >> sorry. > >Greg, > >SSD is coming mainstream and it doesn't make sense wasting time >spinning up "disk" ... > > >Jeff. >-- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" >in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Stop SSD from waiting for "Spinning up disk..." 2015-06-22 7:25 Jeff Chua 2015-06-22 15:36 ` Greg Kroah-Hartman @ 2015-06-25 16:21 ` Henrique de Moraes Holschuh 2015-06-25 16:47 ` Joe Perches 1 sibling, 1 reply; 15+ messages in thread From: Henrique de Moraes Holschuh @ 2015-06-25 16:21 UTC (permalink / raw) To: Jeff Chua; +Cc: Linux Kernel, Christoph Hellwig, Greg Kroah-Hartman On Mon, 22 Jun 2015, Jeff Chua wrote: > There's no need to wait for disk spin-up for USB SSD devices. This patch No, you have to, instead, wait for SSD firmware startup. And looking at the contents of sd_spinup_disk(), I don't think it is safe to just skip it, either. It would be be better to call it sd_start_device()... sd_spinup_disk() should be really fast on anything that properly implements TEST_UNIT_READY and returns "ok, I am ready" when it doesn't need further waits or START_STOP, etc... Anyway, if you get to see the "Spinning up disk..." printk, your unit did not report it was ready, and sd_spinup_disk tried to issue a START_STOP command to signal it to get ready for real work. There's at least one msleep(1000) in the START_STOP path, though. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Stop SSD from waiting for "Spinning up disk..." 2015-06-25 16:21 ` Henrique de Moraes Holschuh @ 2015-06-25 16:47 ` Joe Perches 0 siblings, 0 replies; 15+ messages in thread From: Joe Perches @ 2015-06-25 16:47 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Jeff Chua, Linux Kernel, Christoph Hellwig, Greg Kroah-Hartman On Thu, 2015-06-25 at 13:21 -0300, Henrique de Moraes Holschuh wrote: > On Mon, 22 Jun 2015, Jeff Chua wrote: > > There's no need to wait for disk spin-up for USB SSD devices. This patch > > No, you have to, instead, wait for SSD firmware startup. > > And looking at the contents of sd_spinup_disk(), I don't think it is safe to > just skip it, either. It would be be better to call it sd_start_device()... > > sd_spinup_disk() should be really fast on anything that properly implements > TEST_UNIT_READY and returns "ok, I am ready" when it doesn't need further > waits or START_STOP, etc... > > Anyway, if you get to see the "Spinning up disk..." printk, your unit did > not report it was ready, and sd_spinup_disk tried to issue a START_STOP > command to signal it to get ready for real work. > > There's at least one msleep(1000) in the START_STOP path, though. It might be good to change the msleep(1000) there to a shorter value like 100ms (or maybe less). Perhaps something like this: (with miscellaneous neatening) o Remove unnecessary '.' continuation printk on delays o Remove trailing whitespace o Neaten whitespace and alignment o Convert int spintime to bool and move for better alignment o Remove "only do this at boot time" comment o Remove unnecessary memset casts o Move int retries declaration to inner loop --- drivers/scsi/sd.c | 39 +++++++++++++++++---------------------- 1 file changed, 17 insertions(+), 22 deletions(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 3b2fcb4..c59ed65 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -1744,22 +1744,20 @@ static void sd_spinup_disk(struct scsi_disk *sdkp) { unsigned char cmd[10]; + bool spintime = false; unsigned long spintime_expire = 0; - int retries, spintime; unsigned int the_result; struct scsi_sense_hdr sshdr; int sense_valid = 0; - spintime = 0; - - /* Spin up drives, as required. Only do this at boot time */ + /* Spin up drives, as required. */ /* Spinup needs to be done for module loads too. */ do { - retries = 0; + int retries = 0; do { cmd[0] = TEST_UNIT_READY; - memset((void *) &cmd[1], 0, 9); + memset(&cmd[1], 0, 9); the_result = scsi_execute_req(sdkp->device, cmd, DMA_NONE, NULL, 0, @@ -1777,15 +1775,15 @@ sd_spinup_disk(struct scsi_disk *sdkp) if (the_result) sense_valid = scsi_sense_valid(&sshdr); retries++; - } while (retries < 3 && + } while (retries < 3 && (!scsi_status_is_good(the_result) || ((driver_byte(the_result) & DRIVER_SENSE) && - sense_valid && sshdr.sense_key == UNIT_ATTENTION))); + sense_valid && sshdr.sense_key == UNIT_ATTENTION))); if ((driver_byte(the_result) & DRIVER_SENSE) == 0) { /* no sense, TUR either succeeded or failed * with a status error */ - if(!spintime && !scsi_status_is_good(the_result)) { + if (!spintime && !scsi_status_is_good(the_result)) { sd_print_result(sdkp, "Test Unit Ready failed", the_result); } @@ -1812,7 +1810,7 @@ sd_spinup_disk(struct scsi_disk *sdkp) sd_printk(KERN_NOTICE, sdkp, "Spinning up disk..."); cmd[0] = START_STOP; cmd[1] = 1; /* Return immediately */ - memset((void *) &cmd[2], 0, 8); + memset(&cmd[2], 0, 8); cmd[4] = 1; /* Start spin cycle */ if (sdkp->device->start_stop_pwr_cond) cmd[4] |= 1 << 4; @@ -1821,11 +1819,8 @@ sd_spinup_disk(struct scsi_disk *sdkp) SD_TIMEOUT, SD_MAX_RETRIES, NULL); spintime_expire = jiffies + 100 * HZ; - spintime = 1; + spintime = true; } - /* Wait 1 second for next try */ - msleep(1000); - printk("."); /* * Wait for USB flash devices with slow firmware. @@ -1833,24 +1828,25 @@ sd_spinup_disk(struct scsi_disk *sdkp) * occur here. It's characteristic of these devices. */ } else if (sense_valid && - sshdr.sense_key == UNIT_ATTENTION && - sshdr.asc == 0x28) { + sshdr.sense_key == UNIT_ATTENTION && + sshdr.asc == 0x28) { if (!spintime) { spintime_expire = jiffies + 5 * HZ; - spintime = 1; + spintime = true; } - /* Wait 1 second for next try */ - msleep(1000); } else { /* we don't understand the sense code, so it's * probably pointless to loop */ - if(!spintime) { + if (!spintime) { sd_printk(KERN_NOTICE, sdkp, "Unit Not Ready\n"); sd_print_sense_hdr(sdkp, &sshdr); } break; } - + + /* Wait a bit for next try */ + msleep(100); + } while (spintime && time_before_eq(jiffies, spintime_expire)); if (spintime) { @@ -1861,7 +1857,6 @@ sd_spinup_disk(struct scsi_disk *sdkp) } } - /* * Determine whether disk supports Data Integrity Field. */ ^ permalink raw reply related [flat|nested] 15+ messages in thread
end of thread, other threads:[~2015-06-25 16:49 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-06-23 18:26 Stop SSD from waiting for "Spinning up disk..." Andreas Mohr 2015-06-23 18:55 ` Martin Steigerwald 2015-06-24 16:22 ` Jeff Chua 2015-06-24 16:28 ` Greg Kroah-Hartman 2015-06-24 23:55 ` Jeff Chua 2015-06-25 1:41 ` Greg Kroah-Hartman 2015-06-25 6:08 ` Martin Steigerwald 2015-06-25 8:52 ` Jeff Chua -- strict thread matches above, loose matches on Subject: below -- 2015-06-22 7:25 Jeff Chua 2015-06-22 15:36 ` Greg Kroah-Hartman 2015-06-23 15:02 ` Jeff Chua 2015-06-23 18:27 ` Frans Klaver 2015-06-23 18:51 ` Marc Burkhardt 2015-06-25 16:21 ` Henrique de Moraes Holschuh 2015-06-25 16:47 ` Joe Perches
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.