From mboxrd@z Thu Jan 1 00:00:00 1970 From: michi1@michaelblizek.twilightparadox.com (michi1 at michaelblizek.twilightparadox.com) Date: Fri, 17 Oct 2014 18:47:09 +0200 Subject: epoll improvements In-Reply-To: <47342.1413478933@turing-police.cc.vt.edu> References: <47342.1413478933@turing-police.cc.vt.edu> Message-ID: <20141017164708.GA4289@grml> To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org Hi! On 13:02 Thu 16 Oct , Valdis.Kletnieks at vt.edu wrote: > On Thu, 16 Oct 2014 14:09:05 +0200, "Nev Ikte" said: > > > I've tried to reproduce it with a single client > > and basically, if ep_poll() is able to find an event or the timeout is 0, > > the latency is down to 5usec, otherwise if it enters the waitqueue > > the latency goes up to 10-25usec, which impact the application performance. > > Is it possible that what you're actually measuring here is your CPU's > latency coming out of a sleep state if every task is in a wait queue? I have seen wakeup latencies of ~100usec on some systems. You may want to disable sleep states and see of performance gets better. Take a look at: Documentation/power/pm_qos_interface.txt Also, you probably want disable frequency scaling: /sys/devices/system/cpu/cpu.../cpufreq/scaling_governor should return "performance" for every cpu. You can change it with eche "performance" > /sys/... -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com