You're right. I don't have a real world program that cares.
The program I have is a thing named lantest which is the standard
benchmark benchmark for macintosh file server performace. Actually as
far as I can tell, the only benchmark available.
The reason am bothered by this case is that I feel its bad practise to
leave degenerate performance situations where the kernel performance
really sucks if it can be easily avoided. If you have a hole in kernel
performce where people can get into degenerate performance, sooner or
later someone is going to fall into it and then they're going to blame
the kernel. Sure this may only happen to badly written programs, but its
not as if the world is exactly short of them.
If you take my situation as a case in point, I was asked to evaluate
Linux and Solaris a potential file serving platforms for Mac clients. So
as part of my testing, I fired up lantest as a benchmark. Solaris was
fine, Linux sucked. My conclusion was that Linux was an immature
operating system that still needed some work and we went with Solaris.
Its only because I devoted time and effort into understanding why Linux
did so badly that I now understand that this is not a Linux problem per
se. And I only did that because I wanted to report the problem and help
Linux become a better operating system.
Anyway, as far as I can tell, it would barely affect Linux performance
to do some read ahead in this case. The disk head is already there, it
costs almost nothing to read a few extra 10's or 100's of K's of data.
And it would help eliminate this potentially degenerate case.
-- Robert Cohen Unix Support TLTSU Australian National University Ph: 612 58389 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/