All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jens Axboe <jaxboe@fusionio.com>
Cc: Matthew Wilcox <matthew@wil.cx>, Luben Tuikov <ltuikov@yahoo.com>,
	Greg KH <greg@kroah.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"tj@kernel.org" <tj@kernel.org>
Subject: Re: SCSI TMF processing; tag allocation
Date: Mon, 15 Nov 2010 08:33:15 -0600	[thread overview]
Message-ID: <1289831595.2233.5.camel@mulgrave.site> (raw)
In-Reply-To: <4CE0FD24.4030000@fusionio.com>

On Mon, 2010-11-15 at 10:28 +0100, Jens Axboe wrote:
> >> Third, and most importantly, tags should form an increasing sequence and should not be reused until all other tags after it and before it have been reused. This for example can be accomplished if one were to use
> >> find_next_zero_bit() with non-zero "offset", it being the last allocated
> >> tag in a modulo the number of tags manner. That is, find_next_zero_bit()
> >> could wrap as well as starting from an offset or the caller could implement
> >> that via two calls to this function, in blk_queue_start_tag().
> 
> Care to explain your reasoning? For starvation issues? At least I'm not
> aware of any correctness issues in that regard, but doing tag cycling in
> this fashion seems like a good idea just to prevent starvation alone by
> an ill behaving device.

Right, it's the clock algorithm to prevent tag starvation.  If you have
hands representing the first and last tag and they're never allowed to
cross, the device can't starve any tag for too long because eventually
it will be the only outstanding command.

It's not the only algorithm however.  Banging down an ordered tag every
200 or so commands has exactly the same effect.  In fact the clock
algorithm was what the 53c700 driver used (before it was converted to
generic tags) and the ordered tag what aic7xxx uses.

Realistically, tag starvation isn't really a problem.  It was a known
issue for 80s era hardware.  I've got some of the oldest drives on the
planet and I didn't see a problem when the clock algorithm was removed
from 53c700.

James



  reply	other threads:[~2010-11-15 14:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-06  6:02 SCSI TMF processing; tag allocation Luben Tuikov
2010-11-13 12:37 ` Matthew Wilcox
2010-11-15  9:28   ` Jens Axboe
2010-11-15 14:33     ` James Bottomley [this message]
2010-11-15 14:40       ` Alan Cox
2010-11-15 14:53         ` James Bottomley
2010-11-15 14:46       ` Matthew Wilcox
2010-11-15 14:52         ` James Bottomley
2010-11-16 20:28   ` Vladislav Bolkhovitin
2010-11-15 18:53 ` Douglas Gilbert
2010-11-15 19:09   ` Matthew Wilcox

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=1289831595.2233.5.camel@mulgrave.site \
    --to=james.bottomley@hansenpartnership.com \
    --cc=greg@kroah.com \
    --cc=jaxboe@fusionio.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=ltuikov@yahoo.com \
    --cc=matthew@wil.cx \
    --cc=tj@kernel.org \
    /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.