From: Douglas Gilbert <dougg@torque.net>
To: Kai Makisara <Kai.Makisara@kolumbus.fi>
Cc: Mark Rustad <mrustad@mac.com>,
linux-scsi@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: sg regression in 2.6.16-rc5
Date: Tue, 28 Feb 2006 21:04:45 -0500 [thread overview]
Message-ID: <4405013D.1050407@torque.net> (raw)
In-Reply-To: <Pine.LNX.4.63.0602282216220.6272@kai.makisara.local>
Kai Makisara wrote:
> On Tue, 28 Feb 2006, Douglas Gilbert wrote:
>
>
>>Mark Rustad wrote:
>>
>>>We have encountered some kind of sg regression with kernel 2.6.16-rc5
>>>relative to 2.6.15. We have a small program that demonstrates the
>>>failure. On 2.6.15 it produces the output:
>>>
>>>Alloced dataptr 0 -> 0xb7d07008
>>>IOS: 0
>>>ios 100
>>>
>>>indicating that it did 100 operations successfully. On 2.6.16-rc5, it
>>>produces the output:
>>>
>>>Alloced dataptr 0 -> 0xa7d10008
>>>SG_IO ioctl error 12 Cannot allocate memory
>>>ios 0
>>>
>>>indicating that it did 0 operations successfully. This program is
>>>attempting to do 1MB reads on a SCSI device.
>>
>>Mark,
>>You can stop right there with the 1 MB reads. Welcome
>>to the new, blander sg driver which now shares many
>>size shortcomings with the block subsystem.
>>
>>In lk 2.6.15 the sg driver (and the st driver) did its
>>own scatter gather list allocations. The sg driver
>>used 32 KB segments (8 times the normal page size)
>>in each scatter gather element. The maximum number
>>of scatter gather elements depends on the LLD but
>>can be no more than 256. That meant the sg driver
>>allowed a maximum single IO size of 8 MB. There was
>>also a define in sg.h (SG_SCATTER_SZ and it is still
>>there) that allowed the 32KB per segment to be increased
>>allowing larger single command transfers (then 8 MB).
>>
>
> This is still possible but it needs some changes to most SCSI HBA drivers.
> The big requests are split into bios supporting 256 pages. For 4 kB pages,
> this limits i/o to 1 MB. The scsi_execute_async() path used by st and sg
> can chain bios and this enables large request at the ULD level. At lower
> level, the request consists of pages and now we hit the s/g list maximum
> length _unless_ the HBA driver enables clustering. In this case the
> adjacent pages are coalesced and the large requests fit into the HBA s/g
> limits. Well, now we hit another limit: the max_sectors default for SCSI
> drivers is 1024 and this limits requests to 512 kB _unless_ the HBA driver
> increases max_sectors.
>
> The aic79xx driver enables clustering but does not increase max_sectors.
> This makes the maximum request size 512 kB. If it is possible to set
>
> .max_sectors = 0xFFFF,
>
> in linux/drivers/scsi/aic7xxx/aic79xx_osm.c without breaking the driver,
> this should enable requests up to 8 MB - 256 B. (I don't have the hardware
> to test this.)
>
> Several SCSI HBA drivers currently have similar problems.
Kai,
I applied the above changes to my scsi_debug (plus
extended .sg_tablesize to SG_ALL (it was 64)) and
my single command READs topped out at 4 MB exactly
(bs=512 bpt=8192). When I tried bpt=8193 the
SG_IO ioctl (via a sg device) yielded ENOMEM which
is much more informative than EIO.
That is an improvement.
Doug Gilbert
next prev parent reply other threads:[~2006-03-01 2:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-28 17:54 sg regression in 2.6.16-rc5 Mark Rustad
2006-02-28 19:53 ` Douglas Gilbert
2006-02-28 20:38 ` Kai Makisara
2006-03-01 2:04 ` Douglas Gilbert [this message]
2006-03-01 2:08 ` Mark Rustad
2006-03-01 8:38 ` Matthias Andree
2006-03-01 18:28 ` Linus Torvalds
2006-03-01 18:32 ` Mark Lord
2006-03-01 18:42 ` Linus Torvalds
2006-03-01 18:50 ` Matthew Wilcox
2006-03-03 18:27 ` Steve Byan
2006-03-03 18:55 ` Linus Torvalds
2006-03-03 19:13 ` Steve Byan
2006-03-03 19:42 ` Jeff Garzik
2006-03-03 20:09 ` Linus Torvalds
2006-03-03 20:30 ` Jeff Garzik
2006-03-01 19:33 ` Douglas Gilbert
2006-03-01 20:42 ` Mike Christie
2006-03-01 22:30 ` James Bottomley
2006-03-01 22:56 ` Mike Christie
2006-03-01 21:06 ` Kai Makisara
2006-03-02 19:50 ` Douglas Gilbert
2006-03-02 21:25 ` Linus Torvalds
2006-03-02 23:08 ` Matthias Andree
2006-03-02 23:20 ` Linus Torvalds
2006-03-03 0:02 ` Linus Torvalds
2006-03-03 0:12 ` Linus Torvalds
2006-03-03 16:43 ` Douglas Gilbert
2006-03-03 17:17 ` Linus Torvalds
2006-03-02 23:06 ` Matthias Andree
-- strict thread matches above, loose matches on Subject: below --
2006-03-02 23:04 Falkinder, David Malcolm
2006-03-02 23:04 ` Falkinder, David Malcolm
2006-03-03 20:24 Falkinder, David Malcolm
2006-03-03 21:54 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4405013D.1050407@torque.net \
--to=dougg@torque.net \
--cc=Kai.Makisara@kolumbus.fi \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mrustad@mac.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.