lkml.org 
[lkml]   [1998]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: elevator algorithm bug in ll_rw_blk.c
After following the discussion found about it I have decided to 
have a look at the code itself.

The main macro which is making the decision in the currently used
algorithm to fit the particular request into the queue look the
following way around:

#define IN_ORDER(s1,s2) \
((s1)->rq_dev < (s2)->rq_dev || (((s1)->rq_dev == (s2)->rq_dev && \
(s1)->sector < (s2)->sector)))

I think presonaly that there may be a thinko here.
It looks for ordering of *both*: devices and
sectors. There may be some doubt about the usefullness of ordering
for the sectors. However no doubt ordering of device requests may
at least interferre with the concurrent working of two
independant DMA devices.It doesn't seem to make much of sense
for operations across multiple partitions, since one would expect anyway
that the disk operations are local to partions in typical usage
patterns.

(I doubt that there are really that many programms which are crossing
partition boundaries in single file operations!)

THIS may be the actual reason why someone doing serious benchmarking
of this whole mechanism enabled and disabled may expierence very well
direct speedup from disabling it entierly. (Which I'm seriously
expecting at least in the case that he is using multiple drives with
the swap
partition out of the way of the main working drive and running
concurrently due to DMA.)

SECOND: This may as well be the reason why some persons don't get
significant speedup after enabling DMA.

BTW: why do you all think are the caches on the HD's themself
not much bigger usually then just about 1MEG. Maybe becouse the
on the fly reordering done by those caches doesn't give anything
significant above this limit? Yes I'm expecting quite current
IDE drives to do exactly this if caching is enabled on the hardware
side.

As a conclusion: Anybody trying some real benchmarking on this
*please consider* just the following one line deletion too:

#define IN_ORDER(s1,s2) \
(s1)->sector < (s2)->sector)))

Marcin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:1.189 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site