Via the posix_fadvise(2) API

Can we do better? Yes, indeed: Linux provides the  posix_fadvise(2) system call, allowing an application process to give hints to the kernel on it's pattern of access to file data, via a parameter called advice. Relevant to our example, we can pass advice as the value POSIX_FADV_SEQUENTIAL, POSIX_FADV_WILLNEED, to inform the kernel that we expect to read file data sequentially and that we expect we shall require access to the file's data in the near future. This advice causes the kernel to initiate an aggressive read-ahead of the file's data in sequential order (lower-to-higher file offsets) into the kernel page cache. This will greatly help increase performance.

The signature of the posix_fadvise(2) system call is as follows:

#include <fcntl.h>
int posix_fadvise(int fd, off_t offset, off_t len, int advice);

Clearly, the first parameter fd represents the file descriptor (we refer the reader to Appendix A, File I/O Essentials), and the second and third parameters, offset and len, specify a region of the file upon which we pass the hint or advice via the fourth parameter, advice. (The length is actually rounded up to the page granularity.)

Not only that, the application, upon finishing processing upon a chunk of video data, could even specify to the OS that it will not require that particular piece of memory any longer by invoking posix_fadvise(2) with advice set to the value POSIX_FADV_DONTNEED; this will be a hint to the kernel that it can free up the page(s) of the page cache holding that data, thereby creating space for incoming data of consequence (and for already cached data that may still be useful).

There are some caveats to be aware of. First, it's important for the developer to realize that this advice is really just a hint, a suggestion, to the OS; it may or may not be honored. Next, again, even if the target file's pages are read into the page cache, they could be evicted for various reasons, memory pressure being a typical one. There's no harm in trying though; the kernel will often take the advice into account, and it can really benefit performance. (More advice values can be looked up, as usual, within the man page pertaining to this API.)

Interestingly, and now understandably, cat(1) uses the posix_fadvise(2) system call to inform the kernel that it intends to perform sequential reads until EOF. Using the powerful strace(1) utility on cat(1) reveals the following: ...fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0

Don't get stressed with the fadvise64; it's just the underlying system call implementation on Linux for the posix_fadvise(2) system call.  Clearly, cat(1) has invoked this on the file (descriptor 3), offset 0 and length 0—implying until EOF, and with the advice parameter set to POSIX_FADV_SEQUENTIAL.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset