Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
[replying to my own note] On Wed, May 19, 2010 at 4:18 PM, Bill Bogstad <bogstad-e+AXbWqSrlAAvxtiuMwx3w at public.gmane.org> wrote: > patterns where this is good enough. ? My interest in this thread is > "What mechanisms are available to applications that don't have access > patterns that fit well with the heuristics that developers are willing > to put into the kernel?" ? pread(), readahead(), AIO all seem relevant > to this question. posix_fadvise(fd, offset, len, advice) lets you tell the system what the access pattern on an FD is going to be. You can also pre-cache regions as well. Turns out that posix_fadvise(..., POSIX_FADV_WILLNEED) is basically functionally equivalent to the Linux readahead() call. Except that my Linux documentation says that readahead() is blocking while posix_fadvise(...,POSIX_FADV_WILLNEED) is not. So posix_fadvise() would seem to be much friendlier to single-threaded applications. Other flags include: # define POSIX_FADV_NORMAL 0 /* No further special treatment. */ # define POSIX_FADV_RANDOM 1 /* Expect random page references. */ # define POSIX_FADV_SEQUENTIAL 2 /* Expect sequential page references. */ # define POSIX_FADV_WILLNEED 3 /* Will need these pages. */ # define POSIX_FADV_DONTNEED 4 /* Don't need these pages. */ # define POSIX_FADV_NOREUSE 5 /* Data will be accessed once. */ Looks like great stuff for high IO computing. Bill Bogstad
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |