| Message ID | 1446150079-17530-1-git-send-email-balbi@ti.com |
|---|---|
| State | New |
| Headers | show |
Hi, Matthew Dharm <mdharm-usb@one-eyed-alien.net> writes: > Uhh... I think this is a bad idea. The 120K limit was chosen based on > seeing a lot of devices which broke if you tried to transfer more. At > least, that's my memory. Otherwise, it's a really goofy number. okay, if somebody has some link pointing to that, I'd be glad to have a look. > I certainly wouldn't mind you increasing it in the case of a USB 3.x > device, but not globally. the thing is that his gives me a similar improvement on USB2 devices as well :-) When I use this same USB3 device connected using USB2 cable, I still see some 20%-ish improvement. It went from 33-ish to 41-ish MB/sec. I'll wait for a pointer to this problematic devices. regards > On Thu, Oct 29, 2015 at 1:21 PM, Felipe Balbi <balbi@ti.com> wrote: > >> Instead of using only 120K for transfer size, let's >> increase it to 1024K. This has a very noticeable >> impact on USB3 storage devices. >> >> The following measurements were done with v4.2 on >> the host side and latest linux-next available at the >> time (20151022). Following are results with default >> and modified max_sectors. Each number is the average >> of 100 measurements with each of the two settings. >> >> Pre 244.87 >> Post 322.10 >> >> That's a 24% increase in throughput by just allowing >> more sectors to transferred in a single >> request. Considering there are other SCSI devices >> using 2048 (and sometimes more) max_sectors, this >> shouldn't bring any surprises to anybody other than >> the extra memory used. >> >> Signed-off-by: Felipe Balbi <balbi@ti.com> >> --- >> drivers/usb/storage/scsiglue.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/usb/storage/scsiglue.c >> b/drivers/usb/storage/scsiglue.c >> index dba51362d2e2..36450111e8b8 100644 >> --- a/drivers/usb/storage/scsiglue.c >> +++ b/drivers/usb/storage/scsiglue.c >> @@ -565,8 +565,8 @@ static const struct scsi_host_template >> usb_stor_host_template = { >> /* lots of sg segments can be handled */ >> .sg_tablesize = SCSI_MAX_SG_CHAIN_SEGMENTS, >> >> - /* limit the total size of a transfer to 120 KB */ >> - .max_sectors = 240, >> + /* limit the total size of a transfer to 1024 KB */ >> + .max_sectors = 2048 >> >> /* merge commands... this seems to help performance, but >> * periodically someone should test to see which setting is more >> -- >> 2.6.2 >> >> > > > -- > Matthew Dharm > Maintainer, USB Mass Storage driver for Linux -- balbi
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c index dba51362d2e2..36450111e8b8 100644 --- a/drivers/usb/storage/scsiglue.c +++ b/drivers/usb/storage/scsiglue.c @@ -565,8 +565,8 @@ static const struct scsi_host_template usb_stor_host_template = { /* lots of sg segments can be handled */ .sg_tablesize = SCSI_MAX_SG_CHAIN_SEGMENTS, - /* limit the total size of a transfer to 120 KB */ - .max_sectors = 240, + /* limit the total size of a transfer to 1024 KB */ + .max_sectors = 2048 /* merge commands... this seems to help performance, but * periodically someone should test to see which setting is more
Instead of using only 120K for transfer size, let's increase it to 1024K. This has a very noticeable impact on USB3 storage devices. The following measurements were done with v4.2 on the host side and latest linux-next available at the time (20151022). Following are results with default and modified max_sectors. Each number is the average of 100 measurements with each of the two settings. Pre 244.87 Post 322.10 That's a 24% increase in throughput by just allowing more sectors to transferred in a single request. Considering there are other SCSI devices using 2048 (and sometimes more) max_sectors, this shouldn't bring any surprises to anybody other than the extra memory used. Signed-off-by: Felipe Balbi <balbi@ti.com> --- drivers/usb/storage/scsiglue.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html