Jon Smirl wrote:
On 5/25/06, Andrew Morton <[email protected]> wrote:
These are nice-looking numbers, but one wonders. If optimising
readahead
makes this much difference to postgresql performance then postgresql
should
be doing the readahead itself, rather than relying upon the kernel's
ability to guess what the application will be doing in the future.
Because
surely the database can do a better job of that than the kernel.
That would involve using posix_fadvise(POSIX_FADV_RANDOM) to disable
kernel
readahead and then using posix_fadvise(POSIX_FADV_WILLNEED) to launch
application-level readahead.
Users have also reported that this patch fixes performance problems
from web servers using sendfile(). In the case of lighttpd they
actually stopped using sendfile() for large transfers and wrote a user
space replacement where they could control readahead manually. With
this patch in place sendfile() went back to being faster than the user
space implementation.
Of course, that is something one would expect should be made to work
properly
with the current readahead implementation.
I don't see Wu's patches getting in for a little while yet.
Reproducable test cases (preferably without a whole lot of network clients)
should get this proble fixed.
--
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
