<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 24, 2013 at 4:41 PM, Jann Horn <span dir="ltr"><<a href="mailto:jann@thejh.net" target="_blank">jann@thejh.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, May 23, 2013 at 11:13:15AM +0200, Lukas Larsson wrote:<br>
> On Thu, May 23, 2013 at 10:56 AM, Jann Horn <<a href="mailto:jann@thejh.net">jann@thejh.net</a>> wrote:<br>
><br>
> > On Wed, May 22, 2013 at 06:42:59PM +0200, Lukas Larsson wrote:<br>
> > > You have to poll like that because fd's are not the only thing which can<br>
> > > trigger load on the system. Timeouts for instance are triggered by<br>
> > calling<br>
> > > gettimeofday which means you have to break out of epoll_wait before the<br>
> > > next timeout happens.<br>
> ><br>
> > Why not by specifying a timeout in the epoll_wait call?<br>
> ><br>
><br>
> If you look closely to the strace you can see that for every n:th call<br>
> there is a small timeout given to epoll_wait. This timeout is calculated by<br>
> looking at the next timeout and a number of other factors.<br>
<br>
</div>Does that mean that the couchdb code has set some timer that fires with a high frequency?<br>
Because even when epoll_wait is called with a timeout, the timeout is below one second.<br>
<div class="im"><br></div></blockquote><div><br></div><div>It could mean that there is a timer, there is also a bunch of other internal emulator events which have to be taken care of which could cause the low timeout. <br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
> ><br>
> > > Also the spinning is done to make the system respond<br>
> > > faster to events by delaying sleeping in the kernel.<br>
> ><br>
> > Ah, ok... and that brings a performance gain?<br>
> ><br>
><br>
> It brings a latency gain, which in turn can bring a performance gain.<br>
> Sleeping in the kernel is a (relatively) expensive thing to do and by<br>
> spinning before sleeping the schedulers stay more responsive. You can<br>
> configure this behaviour through the runtime flags +sbwt, +sws, +swt. See<br>
> <a href="http://www.erlang.org/doc/man/erl.html" target="_blank">http://www.erlang.org/doc/man/erl.html</a> for some more details.<br>
<br>
</div>But e.g. on a single-core machine, spinning before sleeping makes no sense, right?<br>
So for single-core machines (VMs/mobile devices), this should be turned off?<br></blockquote><div> </div><div>I'd assume so, but I haven't made any measurements for it. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Btw, what's so expensive about sleeping in the kernel? The context switches?<br>
Trashing the cache?<br>
</blockquote></div>It varies depending on OS and HW combination, but those are the main things. <br></div></div>