On Wed, 2001-12-05 at 11:19, Roy Sigurd Karlsbakk wrote:
> > The XFS read path is really the general linux read path, so the
> > readahead logic is the same for both. Take a look in mm/filemap.c
> > looks for MAX_READAHEAD - it is 31 pages, or 124K bytes, you could
> > probably change the algorithm and bump the maximum in here - however,
> > readahead just queues I/O to the block layer, the block layer has
> > its own maximum sizes for individual I/O requests. You may find
> > upping the readahead limit just pushes the problem down the stack
> > so to speak.
>
> ok. the MAX_READAHEAD is 'int vm_max_readahead = 31' in 2.2.16. I guess
> this is the same as '/proc/sys/vm/max-readahead' (and equally for min-).
>
> What do you think I can do to make Linux make LARGE I/O requests, or at
> least serialize them so I can reduce the seeks?
And last time this came up, you could not change the application,
correct? Otherwise I would say use O_DIRECT in XFS to do the reads,
and use threads in the application to do explicit readahead into
buffers.
Try bumping up the max and see what happens, but I think a lot of the
lower layers will automatically split it again, I don't think the IDE
code goes bigger than 128K anyway.
Steve
>
> --
> Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA
>
> Computers are like air conditioners.
> They stop working when you open Windows.
--
Steve Lord voice: +1-651-683-3511
Principal Engineer, Filesystem Software email: lord@xxxxxxx
|