Control libuv worker thread affinity

[cinderblock]

I'm using this package to control the affinity of my main thread. This seems to work quite well with partrt from rt-tools. I start node using partrt (partrt -v run -c 0x8 rt /usr/bin/node daemon), which puts all of the Node.js process on a single core, and then use this package to move the main event loop thread to its own core. This seems to get me to my main event loop running on a single core and leaves the libuv worker threads on the core they started on. mpstat confirms the computationally intensive main thread takes "100%" of one core's time and the original core still has some load that correlates with IO operations.

Now, I'm trying to get fancier and looking at options for controlling the libuv worker threads' affinity.

Looking at the API for sched_setaffinity, I'm thinking it should technically be possible if I can get the tid of the worker threads. But therein lies the problem - how to get the tid of the worker threads? I suspect the v8 API doesn't quite allow this level of control. Maybe the only way to achieve what I want is to set the affinity of the process as a whole and then manually move the main thread to the original affinity?

Any thoughts on this would be appreciated. My apologies if this was too off topic to ask here.

[saquibkhan]

Hi @cinderblock Did you try the approach you suggested?

[cinderblock]

No, I did not.

[jdmarshall]

Isn’t moving the main thread to a different CPU going to cause memory latency issues?

it seems like people are talking about spawning Unix processes to determine the thread IDs for the processes