This is a discussion on Re: readahead in the 2.6.25+ kernel - Kernel ; Hi John, On Fri, Oct 31, 2008 at 09:00:30PM -0400, John Galloway wrote: > > Hi, > > I'm looking into read ahead issues wrt Ingres, particularly wrt mmap. > I gather (but am not sure) your readahead patches have ...
On Fri, Oct 31, 2008 at 09:00:30PM -0400, John Galloway wrote:
> I'm looking into read ahead issues wrt Ingres, particularly wrt mmap.
> I gather (but am not sure) your readahead patches have been incorporated
> into the 2.6 kernel around 2.6.15, with some simplfications it seems??
> Are you still maintaining a distinct patch set?
The ondemand readahead patch series have been merged into linux 2.6.23/24.
So I no longer maintain out-of-tree readahead patches.
> And can you help me out about how linux readahead will effect mmap() as
> opposed to read()? i.e. is it enabled for mmap() as well?
No, mmap readahead is always a dumb and simple 'read-around' one, and
it seems there is no general interest on improving it.
Currently you have two options to affect mmap readahead performance:
- tune readahead size with command `blockdev --setra'
- tell kernel to use the ondemand readahead routines with
Note that MADV_SEQUENTIAL is safe to use at least for the current
readahead implementation, it won't blindly do aggressive readahead on
seeing MADV_SEQUENTIAL. The flag only switches the readahead routine
from the dumb read-around one to the somehow smarter readahead logic,
which _detects_ sequential patterns for us.
As a long term solution, if you get favorable numbers with MADV_SEQUENTIAL,
that could be a 'first impetus' to improve the default mmap readahead code ;-)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/