All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] add sysfs to dynamically control blk request tag maintenance
Date: Fri, 7 Oct 2005 09:23:33 +0200	[thread overview]
Message-ID: <20051007072328.GO2889@suse.de> (raw)
In-Reply-To: <200510070246.j972kig22629@unix-os.sc.intel.com>

On Thu, Oct 06 2005, Chen, Kenneth W wrote:
> blk_queue_start_tag and blk_queue_end_tag are called for tagging
> I/O to scsi device that is capable of tcq. blk_queue_find_tag is
> a function that utilizes the tag information built up on every I/O.
> 
> However, there aren't many consumers for blk_queue_find_tag, except
> NCR53c700 and tekram-dc390.  Vast majority of scsi drivers don't
> use these tag currently.  So why bother build them at the beginning
> of an I/O and then tear it all down at the end, all doing hard work
> but no other functions in the kernel appears to care.
> 
> Is there another big scheme in the works to use these tags?  If not,
> I'd like to propose we add a sysfs attribute to dynamically control
> whether kernel maintains blk request tag or not.  This has performance
> advantage that we don't needlessly waste CPU cycle on things we throw
> away without using them. Would the following patch be acceptable?
> Comments?

I don't understand the need for this patch - the generic tagging is only
used if the SCSI LLD indicated it wanted it by issuing a
scsi_activate_tcq(). So blk_queue_start_tag() is only called if the LLD
already did a scsi_activate_tcq(), and blk_queue_end_tag() is only
called if the rq is block layer tagged. blk_queue_find_tag() is only
used with direct use of scsi_find_tag(), a function that should (and is)
only usable by users of the generic tagging already.

So please, a description of what problem you are trying to solve would
be appreciated :-)

-- 
Jens Axboe


  reply	other threads:[~2005-10-07  7:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-07  2:46 [RFC] add sysfs to dynamically control blk request tag maintenance Chen, Kenneth W
2005-10-07  7:23 ` Jens Axboe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-10-07  7:35 Chen, Kenneth W
2005-10-07  7:41 ` Jens Axboe
2005-10-07  7:50   ` Arjan van de Ven
2005-10-07  8:06     ` Jens Axboe
2005-10-07  8:25       ` Arjan van de Ven
2005-10-07  7:52 Chen, Kenneth W
2005-10-07  8:07 ` Jens Axboe
2005-10-07  8:04 Chen, Kenneth W
2005-10-07  8:13 Chen, Kenneth W
2005-10-07 16:57 ` Andrew Vasquez
2005-10-07 18:17   ` Jens Axboe

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=20051007072328.GO2889@suse.de \
    --to=axboe@suse.de \
    --cc=kenneth.w.chen@intel.com \
    --cc=linux-kernel@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.