From: Mike Christie <michaelc@cs.wisc.edu>
To: dougg@torque.net
Cc: Linus Torvalds <torvalds@osdl.org>,
Matthias Andree <matthias.andree@gmx.de>,
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: Wed, 01 Mar 2006 14:42:49 -0600 [thread overview]
Message-ID: <1141245769.9586.6.camel@max> (raw)
In-Reply-To: <4405F6F1.9040106@torque.net>
On Wed, 2006-03-01 at 14:33 -0500, Douglas Gilbert wrote:
> Linus Torvalds wrote:
> >
> > On Wed, 1 Mar 2006, Matthias Andree wrote:
> >
> >>On Tue, 28 Feb 2006, Douglas Gilbert wrote:
> >>
> >>
> >>>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.
> >>
> >>What is the reason to break user-space applications like this?
> >
> >
> > Did you read the whole thread? It was a low-level SCSI driver issue, where
> > nothing broke user space, but the command was just fed to the drive
> > differently, which then hit a limit in the driver.
>
> Linus,
> That is an optimistic take. The maximum data carrying
> capacity of a single SCSI command via the SG_IO ioctl
> depends on the maximum data carrying capacity of a
> scatter gather list. Assuming all scatter gather list
> elements carry the same amount of data then the
> maximum capacity is:
> 'max_bytes_per_element * max_num_elements'
>
> Only the latter figure is a "low-level SCSI driver issue"
> whose maximum seems to be SG_ALL (255). It is the former
> figure that has changed. The sg driver in lk 2.6.15 used
> __get_free_pages() with the order set to get 32 KB where
> as the generic routine used now get a single page (usually
> 4 KB).
The current sg driver should use alloc_pages() with an order that should
get 32 KB. If the order being passed to alloc_pages() in sg.c is only
getting one page by default that is bug.
The generic routines now being used can turn that 32KB segment into
multiple 4KB ones if the LLD does not support clustering.
> Kai Makisara proposed changes in the SCSI LLD
> template that made things better in my experiments with
> scsi_debug.
>
> However today James Bottomley confirmed that relying on
> coalescing pages that may be adjacent is not deterministic:
> http://marc.theaimsgroup.com/?l=linux-scsi&m=114122991606658&w=2
>
> That leaves a worst case scatter gather list data capacity
> of (4 * 255) KB if the SCSI LLD (or SATA) uses SG_ALL. That
> is still just under the 1 MB bar that started this thread.
Actually, we will hit the SCSI_MAX_PHYS_SEGMENTS first. It is 128 by
default so (4 * 128) KB. Here is a patch, only compile tested, to
increase SCSI_MAX_PHYS_SEGMENTS to 256.
--- linux-2.6.16-rc4/include/scsi/scsi.h.orig 2006-03-01 14:32:18.000000000 -0600
+++ linux-2.6.16-rc4/include/scsi/scsi.h 2006-03-01 14:33:32.000000000 -0600
@@ -14,7 +14,7 @@
* The maximum sg list length SCSI can cope with
* (currently must be a power of 2 between 32 and 256)
*/
-#define SCSI_MAX_PHYS_SEGMENTS MAX_PHYS_SEGMENTS
+#define SCSI_MAX_PHYS_SEGMENTS 256
/*
next prev parent reply other threads:[~2006-03-01 20:46 UTC|newest]
Thread overview: 33+ 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
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 [this message]
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-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=1141245769.9586.6.camel@max \
--to=michaelc@cs.wisc.edu \
--cc=dougg@torque.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=matthias.andree@gmx.de \
--cc=mrustad@mac.com \
--cc=torvalds@osdl.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).