Hi, On 07/31/2014 08:48 PM, Laszlo T. wrote: > 2014-07-31 16:16 GMT+02:00 Hans de Goede <hdegoede@xxxxxxxxxx>: >> Hi, >> >> On 07/31/2014 03:51 PM, Laszlo T. wrote: >>>>>>> >>>>>>> I tested with lot of values. I'm not totally sure but it looks the 31 >>>>>>> is max number where it is still stable to create an ext4 filesystem. >>>>>> >>>>>> Thanks, that is good to know. Can you try the following patch instead >>>>>> of changing can_queue ? : >>>>>> >>>>>> diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c >>>>>> index 511b229..6cdc1b9 100644 >>>>>> --- a/drivers/usb/storage/uas.c >>>>>> +++ b/drivers/usb/storage/uas.c >>>>>> @@ -1033,6 +1033,7 @@ static int uas_configure_endpoints(struct uas_dev_info *devinfo) >>>>>> 3, 256, GFP_NOIO); >>>>>> if (devinfo->qdepth < 0) >>>>>> return devinfo->qdepth; >>>>>> + devinfo->qdepth = 32; >>>>>> devinfo->use_streams = 1; >>>>>> } >>>>>> >>>>>> >>>>>> Note that the 32 rather then 31 is on purpose. There is 1 stream reserved >>>>>> for non tagged commands, so under normal use a can_queue of 31 will cause >>>>>> streams 2-32 to be used (stream addresses start at 1 not 0). >>>>>> >>>>>> And can you please also do (with the device plugged in): >>>>>> >>>>>> sudo lsusb -v &> lsusb.log and attach lsusb.log to your next mail? >>>>>> >>>>>> Then assuming my alternative patch works, I'll write a patch to allow >>>>>> overriding max qdepth from a quirk + a quirk for your enclosure. >>>>> >>>>> Thank you, I will try it tonight. >>>>> I've already sent the output of lsusb in my first email: >>>>> https://www.mail-archive.com/linux-usb@xxxxxxxxxxxxxxx/msg46005.html >>>> >>>> Ah, I forgot about that one. That one however seems to be with the >>>> device plugged into a usb-2 port, do you have a machine with a usb-3 >>>> port and if so can you do the lsusb with the device plugged into >>>> a usb-3 port (*) ? >>>> >>>> This also raises the question if you've been doing your testing where >>>> using 31 seems to fix things with the device plugged into a usb-2 or a >>>> usb-3 port ? >>>> >>>> Note that my patch won't do anything for the device plugged into >>>> an usb-2 port, in that case you need to change the qdepth = 256 a >>>> few lines higher to qdepth = 32. >>>> >>>> If you've access to both usb-2 and usb-3 ports, it would be good if you >>>> could test with both, and let us know if you you need qdepth = 32 to fix >>>> things in both cases. >>>> >>>> I've just re-read the uas spec and it does not say anything about how to >>>> determine the uas bridge's max qdepth when running in usb-2, so maybe >>>> rather then making this a quirk we need to play it safe and change >>>> the qdepth = 256 to qdepth = 32 unconditionally. In usb-3 mode most >>>> bridges don't seem to support more then 16 or 32 as qdepth, chances >>>> are that for some implementations the same applies to usb-2 mode. >>>> >>>> Given the relative low speed of the usb-2 bus a qdepth of 32 or even >>>> 16 should be more then enough to get most of the benefits of tcq. >>>> >>>> Regards, >>>> >>>> Hans >>>> >>>> >>>> *) usb devices return different descriptors at different speeds >>> >>> All tests were on usb2. >>> I don't have usb3 ports but I will try that at weekend. >>> >>> I'm curious now, am I the first one who has ever tested uas on usb2? >> >> Ni, I've tested it myself too, including running an entire distro >> with gnome3 from an uas disk. >> >> I'll also do some more tests with mkfs.ext4 with my uas disk enclosures >> as that seems to trigger things for you. But for me so far using usb2 is >> not a problem. >> >> Regards, >> >> Hans > > It looks stable with > can_queue = 65536 and qdepth = 32 > on usb2. That is good to hear. > Please share you result when you have chance to test with your enclosure. I've tested 2 different uas enclosures with 3 different disks on usb2, running mkfs.ext4 on a single partition spanning the entire disk, and I could not reproduce, so this seems to be specific to the jmicron chipset your using. Still there is little in harm in just always reducing the usb2 qdepth to 32, that should be plenty to keep things close to maximum possible throughput on usb2. I'll write a patch for this and I'll Cc. you on the patch. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
