Messages in this thread | | | Date | Thu, 5 Mar 1998 08:20:28 +1300 | From | Chris Wedgwood <> | Subject | Re: Patch for block write clustering |
| |
From: Emil Briggs <briggs@bucky.physics.ncsu.edu> Message-Id: <199803040318.WAA14620@bucky.physics.ncsu.edu> To: linux-kernel@vger.rutgers.edu Subject: Patch for block write clustering Cc: H.H.vanRiel@fys.ruu.nl
[...]
With an IDE drive I saw a 600% performance improvement on one (admittedly contrived benchmark). I'm using an IDE rather than my SCSI disk since I don't have any way to control the write caching on my SCSI drive.
I have similar patches I was playing with from 2.1.26 and also saw a massive improvement with IDE drives (although not at high at 600%) but was unable to get any major improvements with SCSI drives.
When I originally did this I also implemented a character device which was used to read the order writes per performed during the last bdflush, and using awk scripts was able to determine how many times the 'head' would have to change direction. (This being dependent on the drives physical geometry). With a reasonable amount of RAM (128MB) its quite surprising just how much unnecessary disk activity there is because of this.
Presumably the same situation may also exist when reading, but I'm not really sure how this can be improved... (I did think of creating a global request queue, and when >= n tasks are waiting or before m ticks, re-order and perform the reads? Doesn't sound very good to me).
The other major concern I had was that if I had many many buffers to flush (say over 100MB) that the sort would take a non-trivial amount of time and actually worsen the situation. I actually wrote use-land code to test this idea by dumping the write-list from the previous bdflush and timing various sorts.... could this be an issue for machines with large amounts of buffers? (Assume worst case time to sort 30,000 elements?) There was also an issue of additional memory required to do all this, but that I'm sure can probably be worked around.
I also used a quick-sort... which obviously is evil because of the large amount of stack required. I think changing to a shell-sort is where I gave up because I couldn't get the sort to work <g>
in the end I managed to side-step the issue my moving to DPT 3224 SCSI controller with hardware striping. Way kewl setup, unfortunately grossly overpriced.
-cw
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |