All of lore.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 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.