lkml.org 
[lkml]   [1999]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SG_BIG_BUF too slid ? ;-)
Meino wrote:
> I am trying to build an new backend for SANE.
> The SANE docs say, that it is recommended to increase sg-big-buf.
> Ok, I thought, an changed /usr/src/linux/include/scsi/sg.h to
> look like:
>
> /*#define SG_BIG_BUFF SG_SCATTER_SZ*/ /* mcc:off for backward compatibility */
> #define SG_BIG_BUFF (SG_SCATTER_SZ * 8) /* =256KB, if you want mcc */

You are obviously using kernel 2.2.6 or later and
seeing the new sg driver.

In the new sg driver, SG_BIG_BUFF exists for backward
compatibility only. There no longer is a single buffer
reserved at driver initialization time for all sg
device users to compete over. [For example, with the
original driver you could not run cdparanoia and SANE
at the same time!]
Instead the new driver gets a reserved buffer for each
new file descriptor on an sg device. The size of that
reserved buffer depends on whether
- the adapter has the 16MB ISA DMA limit
- the adapter does scatter gather
- and, of course, how much memory is available
In short, it is not a constant. So the new driver supplies
an ioctl() [SG_GET_RESERVED_SIZE] to get that value.

> and recompiled the kernel, install it and rebooted.
>
> A cat /proc/sys/kernel/sg-big-buf shows me 32kByte nevertheless.

This /proc/sys/kernel/sg-big-buf is a strange beast. For a
start it is not present when sg is a module. Also the size
of the reserved buffer potentially differs for each open
sg file descriptor. So how do you represent that in
one variable in a backward compatible way? My solution is
to deprecate it and meanwhile place the reserved buffer
size of the most recently opened sg file descriptor in
it.

> What I am doing wrong?
> I expspected too see something like 256kByte...

No, you are not doing anything wrong. SANE documentation
probably needs some tweaking in this area. Better
still the SANE (Linux) transport layer should offer
you some options rather than suggesting the user go
and hack the kernel code. With the old driver, pushing
SG_BIG_BUFF to its maximum of 128KB, building sg
as a module and using a SCSI ISA adapter on a machine
running a 2.2 kernel with lots of memory (perversely)
is a recipe for an oops!

See the "SG_BIG_BUFF and friends" and the
"Memory issues" sections in
http://www.torque.net/sg [follow 'documentation' link]

That documentation discusses a version that is "in
the pipeline", perhaps appearing in the next "ac" kernel.

In the meantime, to see if there is any beneficial effect
from a larger buffer, try increasing SG_SCATTER_SZ to
64KB. If there isn't a significant improvement then I
would put it back to 32 KB.


Doug Gilbert
sg maintainer


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.033 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site