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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
