RejectedSoftware Forums

Am 19.02.2014 04:43, schrieb Etienne:

I'm wondering if vibe.d would be able to take advantage of the "maxcpus" kernel parameter, and using "pthreadsetaffinitynp" to use the inactive CPUs for worker tasks without interruption. I'm not sure if this should belong in libevent though.

This article was using Snort as an example, which is quite interesting because it can somewhat relate to vibe.d quite well:

http://blog.erratasec.com/2013/02/multi-core-scaling-its-not-multi.html#.UwQnPYUVRdQ

"For example, set “maxcpus=2”. This will cause Linux to use only the first two CPUs of the system. Sure, it knows other CPU cores exist, it just will never by default schedule a thread to run on them.

Then what you do in your code is call the “pthreadsetaffinitynp()” function call to put your thread on one of the inactive CPUs (there is Snort configuration option to do this per process). As long as you manually put only one thread per CPU, it will NEVER be interrupted by the Linux kernel. Only if you schedule two threads on a CPU will the interruption happen. Thus, you configure each Snort to run on its own dedicates Snort, and a lot of the jitter in IPS mode goes away."

Using thread affinity to pin each worker thread to a fixed
CPU/core/hwthread should definitely be done, I just didn't do it yet,
because it wasn't important enough so far. But everything else is
usually too application specific for it to make sense to use a
particulary clever default, so we should just make sure that everything
is configurable enough (e.g. number of worker threads or the maxcpus
parameter) and let the user do the rest from the outside.