All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Smart <James.Smart@Emulex.Com>
To: "Martin W. Schlining III" <mschlining@datadirectnet.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: Large Sequential Reads Being Broken Up. Why?
Date: Mon, 30 Jan 2006 11:17:01 -0500	[thread overview]
Message-ID: <43DE3BFD.3090902@emulex.com> (raw)
In-Reply-To: <43DE2EB0.2040700@datadirectnet.com>

Here's one thing that will help you....
   in the lpfc driver (in rev 8.0.13 - the file is lpfc_fcp.c), in the
   scsi_driver_template structure - add the field:
       .max_sectors = 0xFFFF,

As of 2.6.10, the kernel started paying attention to this field, which the
emulex driver, as of that time, didn't set. The result was the kernel
dropped back to a default max_sectors of 1024 - which results in a 512k max.
The lpfc driver was updated in rev 8.0.29 with this change.

Caveat is : Even with this change, you must be using O_DIRECT to get high
bandwidth. Otherwise, the upper layers will segment the requests (if I
remember right, we had a hard time making a "normal" config exceed 256k).

-- james s

Martin W. Schlining III wrote:
> I am running a program on my Linux box which is asking for 2M IO (reads 
> and writes) with the file handle being opened with the O_DIRECT flag. 
> However, the IO being put out on the wire is no larger than 512K.  My 
> target device is the SCSI block device (/dev/sdb in this case). What is 
> preventing me from getting large IO through the SCSI block layer? How 
> can I fix it?
> 
> The sg device can achieve the 2M IO size, so I know its at least 
> possible. How can I improve the IO size for the SCSI block layer?
> 
> Details:
> 
> Dell 2850 server with dual Xeons, 1G RAM
> OS: Linux racerx 2.6.11.4-21.10-smp #1 SMP Tue Nov 29 14:32:49 UTC 2005 
> x86_64 x86_64 x86_64 GNU/Linux
> Emulex LP11000 Fibre Channel HBA using driver version 8.0.13 (changing 
> the driver hasn't helped, so far)
> I set the lookahead value pretty large to improve read performance 
> (hdparm -a)
> The scheduler for this device is anticipatory.
> 
> Any ideas?
> 
> Thanks,
> Martin Schlining
> 
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  parent reply	other threads:[~2006-01-30 16:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-30 15:20 Large Sequential Reads Being Broken Up. Why? Martin W. Schlining III
2006-01-30 15:51 ` David.Egolf
2006-01-30 16:17 ` James Smart [this message]
2006-01-30 16:58   ` James Bottomley
  -- strict thread matches above, loose matches on Subject: below --
2006-01-30 16:51 egoggin

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=43DE3BFD.3090902@emulex.com \
    --to=james.smart@emulex.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mschlining@datadirectnet.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.