From: Matthew Wilcox <matthew@wil.cx>
To: James Smart <James.Smart@Emulex.Com>
Cc: Christof Schmitt <christof.schmitt@de.ibm.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: queue_depth tracking from LLD
Date: Thu, 16 Apr 2009 08:33:50 -0600 [thread overview]
Message-ID: <20090416143350.GD1926@parisc-linux.org> (raw)
In-Reply-To: <49E73D16.9030307@emulex.com>
On Thu, Apr 16, 2009 at 10:13:42AM -0400, James Smart wrote:
> However, for arrays, with multiple luns, the queue depth is usually a
> target-level resource,
> so the midlayer/block-layer's implementation falls on its face fairly
> quickly. I brought this
If the problem were as simple as the resource being target-level instead
of LUN-level, it would be fairly easy to fix (we could do accounting
per-target instead of per-LUN). The problem, AIUI, is multi-initiator
where you can't know whether resources are in use or not.
> up 2 yrs ago at storage summit. What needs to happen is the creation of
> queue ramp-down
> and ramp-up policies that can be selected on a per-lun basis, and have
> these implemented
> in the midlayer (why should the LLDD ever look at scsi command
> results). What will make
> this difficult is the ramp-up policies, as it can be very target
> device-specific or configuration/load
> centric.
While not disagreeing that it's complex, I don't think putting it in the
driver makes it less complex. I completely agree that LLDDs should not
be snooping scsi commands or scsi command results. It should all be in
the midlayer so we all share the same bugs ;-)
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
next prev parent reply other threads:[~2009-04-16 14:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-16 9:36 queue_depth tracking from LLD Christof Schmitt
2009-04-16 14:13 ` James Smart
2009-04-16 14:27 ` Mike Christie
2009-04-16 14:38 ` James Smart
2009-04-16 15:27 ` Christof Schmitt
2009-04-16 15:32 ` James Smart
2009-04-16 14:33 ` Matthew Wilcox [this message]
2009-04-16 14:40 ` James Smart
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=20090416143350.GD1926@parisc-linux.org \
--to=matthew@wil.cx \
--cc=James.Smart@Emulex.Com \
--cc=christof.schmitt@de.ibm.com \
--cc=linux-scsi@vger.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.