Messages in this thread | | | Date | Fri, 04 Feb 2005 09:30:27 +0900 | From | Tejun Heo <> | Subject | Re: [PATCH 2.6.11-rc2 21/29] ide: Merge do_rw_taskfile() and flagged_taskfile(). |
| |
Hello,
Bartlomiej Zolnierkiewicz wrote: > On Wed, 2 Feb 2005 12:06:03 +0900, Tejun Heo <tj@home-tj.org> wrote: > >>>21_ide_do_taskfile.patch >>> >>> Merged do_rw_taskfile() and flagged_taskfile() into >>> do_taskfile(). During the merge, the following changes took >>> place. >>> 1. flagged taskfile now honors HOB feature register. >>> (do_rw_taskfile() did write to HOB feature.) >>> 2. No do_rw_taskfile() HIHI check on select register. Except >>> for the DEV bit, all bits are honored. >>> 3. Uses taskfile->data_phase to determine if dma trasfer is >>> requested. (do_rw_taskfile() directly switched on >>> taskfile->command for all dma commands) >> >>Signed-off-by: Tejun Heo <tj@home-tj.org> > > > do_rw_taskfile() is going to be used by fs requests once > __ide_do_rw_disk() is converted to taskfile transport. > > I don't think that do_rw_taskfile() and flagged_taskfile() merge > is a good thing as it adds unnecessary overhead for hot path > (fs requests).
Yeah, I also thought about that, but here are reasons why I still think merging is better.
1. The added overhead is small. It's just a dozen more if's per every disk io. I don't think it will make any noticeable difference.
2. If hot path optimization is needed, it can be easily done inside one do_taskfile() function with one or two more if's.
3. Currently, do_rw_taskfile() isn't used by __ide_do_rw_disk(). We can think about optimization when actually converting it to use taskfile transport. And IMHO, if hot path optimization is needed, leaving hot path optimization where it is now (inside __ide_do_rw_disk()) is better than moving it to separate taskfile function (do_rw_taskfile()).
-- tejun
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |