Messages in this thread | | | Date | Tue, 25 Jun 2019 13:19:04 +0200 | From | Roman Penyaev <> | Subject | Re: [PATCH v5 00/14] epoll: support pollable epoll from userspace |
| |
On 2019-06-24 22:38, Linus Torvalds wrote: > On Mon, Jun 24, 2019 at 10:42 PM Roman Penyaev <rpenyaev@suse.de> > wrote: >> >> So harvesting events from userspace gives 15% gain. Though bench_http >> is not ideal benchmark, but at least it is the part of libevent and >> was >> easy to modify. >> >> Worth to mention that uepoll is very sensible to CPU, e.g. the gain >> above >> is observed on desktop "Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz", >> but on >> "Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz" measurements are almost >> the >> same for both runs. > > Hmm. 15% may be big in a big picture thing, but when it comes to what > is pretty much a micro-benchmark, I'm not sure how meaningful it is. > > And the CPU sensitivity thing worries me. Did you check _why_ it > doesn't seem to make any difference on the Xeon 4110? Is it just > because at that point the machine has enough cores that you might as > well just sit in epoll() in the kernel and uepoll doesn't give you > much? Or is there something else going on?
This http tool is a singlethreaded test, i.e. client and server work as a standalone processes and each has a single event thread for everything.
According to what I saw there, is that events come slowly (or event loop acts faster?), so when time has come to harvest events there is nothing, we take a slow path and go to kernel in order to sleep. That does not explain the main "why", unfortunately.
I would like to retest that adding more clients to the server, thus server is more likely to observe events in a ring, avoiding sleep.
-- Roman
| |