4 ms·

Playing with madvise MADV_SEQUENTIAL might also add some insight. The author of the original article here did mention different access patterns, but did not us

by cb321 6y ago

Playing with madvise MADV_SEQUENTIAL might also add some insight. The author of the original article here did mention different access patterns, but did not use madvise in any of her published code.

jart 6y ago
madvise is more about good citizenship since kernels are usually tuned with a default strategy of salting the earth to get the best possible score on simple benchmarks: madvise(mapped_addr, mapped_size, MADV_WILLNEED | MADV_SEQUENTIAL); Please call that function before consuming a large file. If you ingest more data than is stored in RAM, then without madvise, you're going to make everything else on the system go really slow afterwards, since every other program that has hot pages in cache waiting to be re-used will become cold and have to hit disk again.
- cb321 6y ago
  @burntsushi's usage context is a highly multi-threaded single process doing many mmap()/munmap()s in parallel. There "being a good citizen" may well mean "not being so hard on your own self", but where the definition of "self" is more complex. Hah. This is starting to sound more like pop psychology than systems programming. :-) :-) Anyway, there are quite a few ways a process can be too hard on itself, self-defeating its own max IO goals. Over in that lobste.rs thread, the idea also arose that, besides L3 cache sharing, the kernel may be locking the whole process to edit VM mappings during both mmap and munmap. A sibling(-ish) comment here mentions sharing another cache -- the TLB for Virtual->Physical translation. It's hard to say what the whole mix for `ripgrep` winds up being in various deployment scenarios without more investigation. Another "self"-competition example would definitely be waiting for disk head movement on Winchester drives, but `rg` is mostly a child of the SSD/Flash generation.

4 ms·

Playing with madvise MADV_SEQUENTIAL might also add some insight. The author of the original article here did mention different access patterns, but did not us

by cb321 6y ago

Playing with madvise MADV_SEQUENTIAL might also add some insight. The author of the original article here did mention different access patterns, but did not use madvise in any of her published code.

jart 6y ago
madvise is more about good citizenship since kernels are usually tuned with a default strategy of salting the earth to get the best possible score on simple benchmarks: madvise(mapped_addr, mapped_size, MADV_WILLNEED | MADV_SEQUENTIAL); Please call that function before consuming a large file. If you ingest more data than is stored in RAM, then without madvise, you're going to make everything else on the system go really slow afterwards, since every other program that has hot pages in cache waiting to be re-used will become cold and have to hit disk again.
- cb321 6y ago
  @burntsushi's usage context is a highly multi-threaded single process doing many mmap()/munmap()s in parallel. There "being a good citizen" may well mean "not being so hard on your own self", but where the definition of "self" is more complex. Hah. This is starting to sound more like pop psychology than systems programming. :-) :-) Anyway, there are quite a few ways a process can be too hard on itself, self-defeating its own max IO goals. Over in that lobste.rs thread, the idea also arose that, besides L3 cache sharing, the kernel may be locking the whole process to edit VM mappings during both mmap and munmap. A sibling(-ish) comment here mentions sharing another cache -- the TLB for Virtual->Physical translation. It's hard to say what the whole mix for `ripgrep` winds up being in various deployment scenarios without more investigation. Another "self"-competition example would definitely be waiting for disk head movement on Winchester drives, but `rg` is mostly a child of the SSD/Flash generation.