public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: "Justin T. Gibbs" <gibbs@scsiguy.com>,
	William Lee Irwin III <wli@holomorphy.com>,
	linux-kernel@vger.kernel.org, axel@pearbough.net
Subject: Re: drivers/scsi/aic7xxx/aic7xxx_osm.c: warning is error
Date: Wed, 14 May 2003 09:54:07 +0200	[thread overview]
Message-ID: <20030514075407.GA10685@suse.de> (raw)
In-Reply-To: <20030514073700.GA3151@beaverton.ibm.com>

On Wed, May 14 2003, Mike Anderson wrote:
> Justin T. Gibbs [gibbs@scsiguy.com] wrote:
> > Comments have indicated since the 2.4.X days that Linux will never allocate
> > segments that cross a 4GB boundary.  If this is truely enforced, then this
> > code can just be removed.  It was only added out of paranoia (hence the
> > printf) while adding high address support to the driver.
> 
> Jens can give the more complete answer on enforcement, and also correct
> any mis-statements I made.

This property can be toggled with blk_queue_segment_boundary, and we do
default to setting a 4GB boundary mask. So you can be sure that a
request will never straddle a 4GB boundary.

> Base on the queue values below the aic7xxx driver should see the
> following characteristics on IO. The IO should be for no more than 8k
> made up of no more than 128 sg entries with no segment crossing the
> seg_boundary_mask.

I suppose you mean for no more than 8k sectors, ie 4MiB of data.

> Adaptec AIC7xxx driver version: 6.2.33
> scsi_alloc_queue: queue for aic7xxx
> bounce_pfn: 0xfffff
> bounce_gfp: 0x10 (GFP_NOIO)
> queue_flags: 0x1 (QUEUE_FLAG_QUEUED)
> max_sectors: 0x2000 (8192)
> max_phys_segments: 0x80 (128)
> max_hw_segments: 0x80 (128)
> hardsect_size: 0x200 (512)
> max_segment_size: 0x10000 (65536)
> seg_boundary_mask: 0xffffffff

that is the key here.

> dma_alignment: 0x1ff (511)

So to recap, aic7xxx will never see a request that exceeds one of the
above values. Total request size will always be equal to or below 4MiB,
less than or equal to 128 segments, and will never cross a 4GB memory
boundary. Memory above pfn 0xfffff (4GB) will be bounced, but this could
be because that's just the amount of memory the box has you dumped this
info from.

-- 
Jens Axboe


  reply	other threads:[~2003-05-14  7:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-14  0:40 drivers/scsi/aic7xxx/aic7xxx_osm.c: warning is error axel
2003-05-14  1:29 ` William Lee Irwin III
2003-05-14  1:41   ` axel
2003-05-14  3:18 ` William Lee Irwin III
2003-05-14  4:57   ` William Lee Irwin III
2003-05-14  6:05   ` Justin T. Gibbs
2003-05-14  6:16     ` William Lee Irwin III
2003-05-14  7:37     ` Mike Anderson
2003-05-14  7:54       ` Jens Axboe [this message]
2003-05-14  8:20         ` William Lee Irwin III
2003-05-14 15:56         ` Mike Anderson

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=20030514075407.GA10685@suse.de \
    --to=axboe@suse.de \
    --cc=axel@pearbough.net \
    --cc=gibbs@scsiguy.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wli@holomorphy.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox