Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Pathological cases

Posted Feb 5, 2010 10:41 UTC (Fri) by alex (subscriber, #1355)
Parent article: Improving readahead

One pathological case I cam across recently is the handling of RRD files.
Updates to RRD files tend to be to the header and one other block in the
file. Most of the time any readahead is a complete waste of time from an
efficient I/O point of view.

Do the readahead heuristics handle the case where the readahead is never
actually used by the process? Just turning down the global readahead knob is
a rather clunky solution as I'm sure it's useful for a lot of other cases
(spooling programs up for example).

(Log in to post comments)

Pathological cases

Posted Feb 5, 2010 11:03 UTC (Fri) by farnz (guest, #17727) [Link]

That sort of situation is what posix_fadvise is meant for. If you know in advance that readahead will be wasted, posix_fadvise(fd, 0, 0, POSIX_FADV_RANDOM); tells the kernel not to bother.

In general, if you know that you have an abnormal access pattern ahead of time, the right call to posix_fadvise won't hurt you, and can help.

Pathological cases

Posted Feb 5, 2010 14:10 UTC (Fri) by corbet (editor, #1) [Link]

Yes, the readahead code tracks hits and stops trying when the program skips around a lot - that happens now. One other little heuristic in this patch set that I didn't work into the article is a tweak which suppresses readahead when the application seeks to the beginning of the file. That should nicely take care of the "update the header" case described here.