From dae35bac98520c1402d29c60df11a2993889ec85 Mon Sep 17 00:00:00 2001 From: Joey Degges Date: Mon, 1 Mar 2010 10:26:22 +0000 Subject: 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. --- m4/jm-macros.m4 | 1 + 1 file changed, 1 insertion(+) (limited to 'm4') diff --git a/m4/jm-macros.m4 b/m4/jm-macros.m4 index 0ddbf2fdc..d4e20f9c1 100644 --- a/m4/jm-macros.m4 +++ b/m4/jm-macros.m4 @@ -64,6 +64,7 @@ AC_DEFUN([coreutils_MACROS], LIBS=$coreutils_saved_libs # Used by sort.c. + AC_CHECK_FUNCS_ONCE([posix_fadvise]) AC_CHECK_FUNCS_ONCE([nl_langinfo]) # Used by tail.c. -- cgit v1.2.3-70-g09d2