On 09/18/2013 02:09 PM, Jason Baron wrote:
On 09/13/2013 11:54 AM, Nathan Zimmer wrote:
We noticed some scaling issue in the SPECjbb benchmark. Running perf
we found that the it was spending lots of time in SYS_epoll_ctl.
In particular it is holding the epmutex.
This patch helps by moving out the kmem_cache_alloc and kmem_cache_free out
from under the lock. It improves throughput by around 15% on 16 sockets.
While this patch should be fine as it is there are probably is more things
that can be done out side the lock, like wakeup_source_unregister, but I am
not familar with the area and I don't know of many tests. I did find the
one posted by Jason Baron at https://lkml.org/lkml/2011/2/25/297.
Any thoughts?
Hi,
Intersting - I think its also possible to completely drop taking the
'epmutex' for EPOLL_CTL_DEL by using rcu, and restricting it on add
to more 'complex' topologies. That is when we have an epoll descriptor
that doesn't nest with other epoll descriptors, we don't need the
global 'epmutex' either. Any chance you can re-run with this? Its a bit
hacky, but we can clean it up if it makes sense.
Thanks,
-Jason
That is working GREAT. It is scaling to 16 jobs quite well.
I will have to grab a larger machine( to see what the new scaling curve
will be.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
