James Bottomley wrote:
if (BLK_DEF_MAX_SECTORS > max_sectors)
q->max_hw_sectors = q->max_sectors = max_sectors;
else {
q->max_sectors = BLK_DEF_MAX_SECTORS;
q->max_hw_sectors = max_sectors;
}
}
So it imposes a maximum possible setting of BLK_DEF_MAX_SECTORS which is
defined in blkdev.h to .... 1024, thus also forcing the queue down to
128 scatterlist entries.
Once I raised this limit as well, I was able to transfer over 128
scatterlist elements during benchmark test runs of normal I/O (actually
kernel compiles seem best, they hit 608 scatterlist entries).
So my question, is there any reason not to raise this limit to something
large (like 65536) or even eliminate it altogether?
ISTR a thread long ago, perhaps including Andrea A (as well as Jens),
where 1024 sectors was arrived upon as a reasonable balance between
tying up gobs of VM memory on a single command (multiplied, then, across
N commands), and getting decent per-command throughput.
Jens probably recalls better than I... but I'm pretty sure that the
1024 limit played into "being nice with the VM" somehow.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
