Re: [PATCH v2] Sleep 1 millisecond in poll() to avoid busy wait

[Erik Faye-Lund <kusmabite@gmail.com>]

On Mon, Apr 28, 2014 at 5:35 PM, Stepan Kasal <kasal@ucw.cz> wrote:
> From: theoleblond <theodore.leblond@gmail.com>
> Date: Wed, 16 May 2012 06:52:49 -0700
>
> SwitchToThread() only gives away the rest of the current time slice
> to another thread in the current process. So if the thread that feeds
> the file decscriptor we're polling is not in the current process, we
> get busy-waiting.
>
> I played around with this quite a bit. After trying some more complex
> schemes, I found that what worked best is to just sleep 1 millisecond
> between iterations. Though it's a very short time, it still completely
> eliminates the busy wait condition, without hurting perf.
>
> There code uses SleepEx(1, TRUE) to sleep. See this page for a good
> discussion of why that is better than calling SwitchToThread, which
> is what was used previously:
> http://stackoverflow.com/questions/1383943/switchtothread-vs-sleep1
>
> Note that calling SleepEx(0, TRUE) does *not* solve the busy wait.
>
> The most striking case was when testing on a UNC share with a large repo,
> on a single CPU machine. Without the fix, it took 4 minutes 15 seconds,
> and with the fix it took just 1:08! I think it's because git-upload-pack's
> busy wait was eating the CPU away from the git process that's doing the
> real work. With multi-proc, the timing is not much different, but tons of
> CPU time is still wasted, which can be a killer on a server that needs to
> do bunch of other things.
>
> I also tested the very fast local case, and didn't see any measurable
> difference. On a big repo with 4500 files, the upload-pack took about 2
> seconds with and without the fix.
> ---
>
> On Mon, Apr 28, 2014 at 05:05:47PM +0200, Johannes Sixt wrote:
>> [...] but I very much prefer the commit message of the earlier post.
>
> ... but Paolo had a nice short description of the issue there;
> I inserted that to the top of the earlier commit message.
>
> The latter diff (without the comment), gets us closer to gnulib's poll.c.
>

Good stuff!