From: Andre Noll <maan@tuebingen.mpg.de>
Date: Sun, 6 Aug 2017 12:05:36 +0000 (+0200)
Subject: vss: Remove self-made prefaulting.
X-Git-Tag: v0.6.1~27
X-Git-Url: http://git.tuebingen.mpg.de/?p=paraslash.git;a=commitdiff_plain;h=7bcce4a433d575b15bfb70b7274562d65dd4bd66;ds=sidebyside

vss: Remove self-made prefaulting.

It used to help a bit on a very old laptop with broken IDE hardware,
see commit 7bba6232 (vss: Mmap audio files using MAP_POPULATE) from
six years ago. But even there it did not eliminate buffer underruns
completely. Our prefault code is too ugly to live, and its benefits
are questionable at best, so let's get rid of it.

We still map the audio file with MAP_POPOLATE, which should be enough
get the full audio file cached before chunks are sent.
---

diff --git a/vss.c b/vss.c
index 77d2f376..f225aa74 100644
--- a/vss.c
+++ b/vss.c
@@ -1078,25 +1078,6 @@ static void vss_send(struct vss_task *vsst)
 			senders[i].send(mmd->current_chunk, mmd->chunks_sent,
 				buf, len, vsst->header_buf, vsst->header_len);
 		}
-		/*
-		 * Prefault next chunk(s)
-		 *
-		 * If the backing device of the memory-mapped audio file is
-		 * slow and read-ahead is turned off or prevented for some
-		 * reason, e.g. due to memory pressure, it may take much longer
-		 * than the chunk interval to get the next chunk on the wire,
-		 * causing buffer underruns on the client side. Mapping the
-		 * file with MAP_POPULATE seems to help a bit, but it does not
-		 * eliminate the delays completely. Moreover, it is supported
-		 * only on Linux. So we do our own read-ahead here.
-		 */
-		if (mmd->current_chunk > 0) { /* chunk 0 might be on the heap */
-			buf += len;
-			for (i = 0; i < 5 && buf < vsst->map + vsst->mapsize; i++) {
-				__a_unused volatile char x = *buf;
-				buf += 4096;
-			}
-		}
 		mmd->chunks_sent++;
 		mmd->current_chunk++;
 	}