From: Grant Grundler <grundler@dsl2.external.hp.com>
To: Richard Hirst <rhirst@linuxcare.com>
Cc: Vlad Markov <markov@monmouth.com>, parisc-linux@lists.parisc-linux.org
Subject: [parisc-linux] Re: tag starvation
Date: Fri, 25 Jan 2002 22:28:33 -0700 [thread overview]
Message-ID: <20020126052834.1F31C482A@dsl2.external.hp.com> (raw)
In-Reply-To: Message from Richard Hirst <rhirst@linuxcare.com> of "Fri, 25 Jan 2002 09:57:55 GMT." <20020125095755.GH32617@sleepie.demon.co.uk>
Richard Hirst wrote:
> I used to get this a lot, until James changed the driver to only report
> the first occurance of it. Don't remember the exact details, but iirc
> it is for info only, and non-fatal. From the code it looks like it
> means some cmnd has been sitting in the drive unprocessed for too long,
> and the code rejects new cmds until those older ones have been processed
> or timed out.
Ah ok...does "starvation" properly described by the following scenario?
While the drive is completing IO requests as fast as it can,
*some* IO's don't complete because they never become the most
optimal one to complete. This is an inherent "unfairness"
in the normal SCSI Queue tag. (Two other types of tags exist but
are never used by Unix OS's AFAICT: ordered, Head)
HP branded (and tested) drives are required to return a completion
for any outstanding IO within 3 seconds. ie if 8 tags are active
any given time, the drive can complete the IO's in any order until
an IO reaches this 3 second limit. The reason for the limit is
to prevent outstanding file system meta data from locking up access
to portions the file system for 30+ seconds.
> Hmm, I thought that would be a feature of a specific driver, not the
> upper layers. 53c700.c doesn't (yet) have any boot options to disable
> tags.
hmmm...could we just replace the following constant with
a MODULE_PARAM() variable?
53c700.h:#define NCR_700_MAX_TAGS 16
In the interim, I suggest reducing this until the problem
goes away for that disk.
IIRC, HPUX allows the user to set this on a per disk basis
using scsictl command.
thanks,
grant
next prev parent reply other threads:[~2002-01-26 5:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200201240200.VAA00858@monmouth.com>
2002-01-25 6:55 ` [parisc-linux] Re: tag starvation Grant Grundler
2002-01-25 9:57 ` Richard Hirst
2002-01-26 5:28 ` Grant Grundler [this message]
2002-01-26 17:22 ` Richard Hirst
2002-01-26 17:23 James Bottomley
2002-01-27 8:41 ` Grant Grundler
2002-01-27 16:52 ` James Bottomley
2002-01-27 19:05 ` Grant Grundler
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=20020126052834.1F31C482A@dsl2.external.hp.com \
--to=grundler@dsl2.external.hp.com \
--cc=markov@monmouth.com \
--cc=parisc-linux@lists.parisc-linux.org \
--cc=rhirst@linuxcare.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