If I increase the size of the LRU in NWFS to a size above 3000 buffers,
Linux starts getting SLOWER .... SLOOOWWWWWWERRRR......
SLOOOOOOOWWWWWWEEEERR ..... which is counter intuitive since more cache
should get faster performance. The performance degredation as I
increase the LRU in size is @ log2N, which would seem to indicate that
somewhere down inside of linux, as some linked lists start getting
longer, Linux really bogs down and exhibits asymtopic behavior.
The code we are testing IS NOT the nwfs0331.zip post with the brute
force AIO routine in async.c, but an improved version that allows very
rapid inserts (it combines an extensible double hash for the disk bins,
we never probe deeper than two levels to locate an insertion point in
the AIO elevator).
This would indicate that Linux cannot handle large numbers of AIO
requests at one time (right now the AIO process will flush up to 3000
requests in one pass). When I crank this number back to under 500 AIO's
at one time, then linux performance gets really good.
This would seem to indicate some bottlenecks for handling large numbers
of AIO requests at once. The code causing this is attached. Block.c
and ASYNC.C.
I will post the updated 2.2.15 release tommorrow with the fix for Steve
Hirsch and all the other problems folks have found in the past few
weeks, and the 2.4 page cache stuff. We have also increased the disk
support to 128 SCSI disks, 128 I2O disk, all the ATA Parallel Port Stuff
and up to 10 IDE interfaces (implemented all the max values in
devices.txt). We also have the gendisk stuff in for 2.4, 2.2, and 2.0
and it works great. Thanks to Stephen Tweedie.
:-)
Was seeing this problem and at first glance, thought it was ours, but it
is not.
Jeff Merkey
CEO, TRG
-
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/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:15 EST