sort: inform the system about our input access pattern

Tell the system that we'll access input sequentially,
so that we more efficiently process uncached files in a few cases:

Reading from faster flash devices. E.g. 21 MB/s key:
  NORMAL     31.6s (26.8 user)
  SEQUENTIAL 27.7s
  WILLNEED   27.7s

Processing in parallel with readahead when using a small 1M buffer:
  NORMAL     24.7s (21.1 user)
  SEQUENTIAL 22.7s
  WILLNEED   25.6s

A small benefit when merging:
  NORMAL     25.0s (16.9 user)
  SEQUENTIAL 24.6s (16.6 user)
  WILLNEED   38.4s (13.1 user)

Note WILLNEED is presented above for comparison to show it
has some unwanted characteristics due to its synchronous
prepopulation of the cache. It has a good benefit on a
mechanical disk @ 80MB/s and a multicore system with
competing processes:
  NORMAL     14.73s
  SEQUENTIAL 10.95s
  WILLNEED   05.22s
However the scheduling differences causing this result
are probably best explicitly managed using `nice` etc.

* m4/jm-macros.m4 (coreutils_MACROS): check for posix_fadvise().
* src/sort.c (fadvise_input): A new function to apply
the POSIX_FADV_SEQUENTIAL hint to an input stream.
(stream_open): Call the above function for all input streams.

0 files changed, 0 insertions, 0 deletions