From: Matthew Jacob <mjacob@feral.com>
To: Jens Axboe <axboe@suse.de>
Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>,
"Pedro M. Rodrigues" <pmanuel@myrealbox.com>,
Mathieu Chouquet-Stringer <mathieu@newview.com>,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Warning - running *really* short on DMA buffers while doing file transfers
Date: Thu, 26 Sep 2002 23:50:08 -0700 (PDT) [thread overview]
Message-ID: <Pine.BSF.4.21.0209262344250.17672-100000@beppo> (raw)
In-Reply-To: <20020927063616.GO5646@suse.de>
> > > scsi_dma crap. That said, 253 default depth is a bit over the top, no?
> >
> > Why? Something like a large Hitachi 9*** storage system can take ~1000
> > tags w/o wincing.
>
> Yeah, I bet that most of the devices attached to aic7xxx controllers are
> exactly such beasts.
>
> I didn't say that 253 is a silly default for _everything_, I think it's
> a silly default for most users.
>
Well, no, I'm not sure I agree. In the expected life time of this
particular set of software that gets shipped out, the next generation of
100GB or better disk drives will be attached, and they'll likely eat all
of that many tags too, and usefully, considering the speed and bit
density of drives. For example, the current U160 Fujitsu drives will
take ~130 tags before sending back a QFULL.
On the other hand, we can also find a large class of existing devices
and situations where anything over 4 tags is overload too.
With some perspective on this, I'd have to say that in the last 25 years
I've seen more errors on the side of 'too conservative' for limits
rather than the opposite.
That said, the only problem with allowing such generous limits is the
impact on the system, which allows you to saturate as it does. Getting
that fixed is more important than saying a driver writer's choice for
limits is 'over the top'.
next prev parent reply other threads:[~2002-09-27 6:44 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-26 3:27 Warning - running *really* short on DMA buffers while doing file transfers Mathieu Chouquet-Stringer
2002-09-26 6:14 ` Jens Axboe
2002-09-26 7:04 ` Pedro M. Rodrigues
2002-09-26 15:31 ` Justin T. Gibbs
2002-09-27 6:13 ` Jens Axboe
2002-09-27 6:33 ` Matthew Jacob
2002-09-27 6:36 ` Jens Axboe
2002-09-27 6:50 ` Matthew Jacob [this message]
2002-09-27 6:56 ` Jens Axboe
2002-09-27 7:18 ` Matthew Jacob
2002-09-27 7:24 ` Jens Axboe
2002-09-27 7:29 ` Matthew Jacob
2002-09-27 7:34 ` Matthew Jacob
2002-09-27 7:45 ` Jens Axboe
2002-09-27 8:37 ` Matthew Jacob
2002-09-27 10:25 ` Jens Axboe
2002-09-27 12:18 ` Matthew Jacob
2002-09-27 12:54 ` Jens Axboe
2002-09-27 13:30 ` Justin T. Gibbs
2002-09-27 14:26 ` James Bottomley
2002-09-27 14:33 ` Jens Axboe
2002-09-27 16:26 ` Justin T. Gibbs
2002-09-27 17:21 ` James Bottomley
2002-09-27 18:56 ` Justin T. Gibbs
2002-09-27 19:07 ` Warning - running *really* short on DMA buffers while doingfile transfers Andrew Morton
2002-09-27 19:16 ` Justin T. Gibbs
2002-09-27 19:36 ` Warning - running *really* short on DMA buffers while doingfiletransfers Andrew Morton
2002-09-27 19:52 ` Justin T. Gibbs
2002-09-27 21:13 ` James Bottomley
2002-09-27 21:18 ` Matthew Jacob
2002-09-27 21:23 ` James Bottomley
2002-09-27 21:29 ` Justin T. Gibbs
2002-09-27 21:32 ` Matthew Jacob
2002-09-27 22:08 ` Mike Anderson
2002-09-30 23:49 ` Doug Ledford
2002-09-27 21:28 ` Justin T. Gibbs
2002-09-28 15:52 ` James Bottomley
2002-09-28 23:25 ` Luben Tuikov
2002-09-29 2:48 ` James Bottomley
2002-09-30 8:34 ` Jens Axboe
2002-09-29 4:00 ` Justin T. Gibbs
2002-09-29 15:45 ` James Bottomley
2002-09-29 16:49 ` [ getting OT ] " Matthew Jacob
2002-09-30 19:06 ` Luben Tuikov
2002-09-30 23:54 ` Doug Ledford
2002-09-27 19:58 ` Andrew Morton
2002-09-27 20:58 ` Warning - running *really* short on DMA buffers while doing file transfers Justin T. Gibbs
2002-09-27 21:38 ` Patrick Mansfield
2002-09-27 22:08 ` Justin T. Gibbs
2002-09-27 22:28 ` Patrick Mansfield
2002-09-27 22:48 ` Justin T. Gibbs
2002-09-27 18:59 ` Warning - running *really* short on DMA buffers while doingfile transfers Andrew Morton
2002-09-27 14:30 ` Warning - running *really* short on DMA buffers while doing file transfers Jens Axboe
2002-09-27 17:19 ` Justin T. Gibbs
2002-09-27 18:29 ` Rik van Riel
2002-09-27 14:56 ` Rik van Riel
2002-09-27 15:34 ` Matthew Jacob
2002-09-27 15:37 ` Jens Axboe
2002-09-27 17:20 ` Justin T. Gibbs
2002-09-27 12:28 ` Pedro M. Rodrigues
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=Pine.BSF.4.21.0209262344250.17672-100000@beppo \
--to=mjacob@feral.com \
--cc=axboe@suse.de \
--cc=gibbs@scsiguy.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mathieu@newview.com \
--cc=pmanuel@myrealbox.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;
as well as URLs for NNTP newsgroup(s).