All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@steeleye.com>
To: Patrick Mansfield <patmans@us.ibm.com>
Cc: Christoph Hellwig <hch@lst.de>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] fixes and cleanups for the new command allocation code
Date: 04 Feb 2003 19:53:57 -0600	[thread overview]
Message-ID: <1044410039.3485.61.camel@mulgrave> (raw)
In-Reply-To: <20030204172505.A28812@beaverton.ibm.com>

On Tue, 2003-02-04 at 19:25, Patrick Mansfield wrote:
> But if we have a lot of prepped commands around we will be allocating
> memory that is not (currently) needed, we could end up using an equal
> number of scsi_cmnd's as we have blk requests. I would rather we not
> allocate or hold onto scsi_cmnd in such cases. (And generally in all
> cases, but that goes beyond.)

But that's not how the block queue works: prep is actually called from
elv_next_request().  Therefore, if you plug the queue in the request
function when you're over the queue limit, you only get a single fully
prepped request waiting in the queue, which, I think, is the desired
behaviour.  Even if the queue is restarted because of I/O pressure, it
will begin with the prepped request and re-block.

> We are still missing single_lun checking.

And the slave_{alloc,configure,destroy} needs fixing too.

> I would like to see the patch in a tree before 2.5.60 (probably already
> too late), and then we can take care of these other issues. I think some
> systems/disks will barf if they are flooded with QUEUE FULLs.

OK, I concur, we can't do without throttling. I'll put it in and we can
try to fix up around it.

James



  reply	other threads:[~2003-02-05  1:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-04 15:23 [PATCH] fixes and cleanups for the new command allocation code Christoph Hellwig
2003-02-04 16:16 ` Patrick Mansfield
2003-02-04 16:51   ` Christoph Hellwig
2003-02-04 17:19     ` Patrick Mansfield
2003-02-04 17:57       ` Luben Tuikov
2003-02-04 18:03         ` Christoph Hellwig
2003-02-04 18:08           ` Luben Tuikov
2003-02-04 18:33       ` James Bottomley
2003-02-04 19:29         ` Christoph Hellwig
2003-02-04 23:03           ` James Bottomley
2003-02-05  1:25             ` Patrick Mansfield
2003-02-05  1:53               ` James Bottomley [this message]
2003-02-05  5:15                 ` Patrick Mansfield
2003-02-05 15:22                   ` James Bottomley
2003-02-05 15:59                     ` James Bottomley

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=1044410039.3485.61.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=hch@lst.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=patmans@us.ibm.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.