Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set core affinity to processor threads #75

Open
rasaoskuei opened this issue Nov 10, 2022 · 4 comments
Open

Set core affinity to processor threads #75

rasaoskuei opened this issue Nov 10, 2022 · 4 comments

Comments

@rasaoskuei
Copy link

In order to reduce OS context switch overhead, it's good to set core affinity to the processor thread (the user can isolate the specific core from the OS scheduler and use it) to fix the core that will execute the processor function.

@Lukas955
Copy link
Collaborator

Hi,

thank you for suggestion. Do you have a preferred way of setting application affinity? It can be set after the start of the application, e.g. using taskset command. Alternatively, we could add a parameter directly specifying the mask where the application threads can run e.g.: ipfixcol2 -a mask ....

Is this what you have in mind?

Lukas

@rasaoskuei
Copy link
Author

rasaoskuei commented Nov 13, 2022

Hi Lukas, thanks for your attention

The main point is about the main processor thread. Suppose you have a thread that processes the IPFIX messages and also you have some other signaling threads maybe. Only the affinity of the processor thread is important, if I do this with taskset then we give n CPU cores to all the threads and all threads (specifically the processor thread) will be switched between n cores.

In my opinion, pthread_setaffinity_np from UNIX pthread is the proper API to set the core affinity, because you just set a specific thread core. Also, we can isolate some CPU cores from the OS scheduler and set them to some processors.
What do you think about this?

@Lukas955
Copy link
Collaborator

Hi,

The collector does not have a single process thread. In fact, it is quite parallel. If you look at the picture in the documentation, each block (i.e. plugin instance) represents a single thread. Moreover, there are other "hidden" processing threads - a packet parser thread after each input plugin instance and one output manager thread between the last intermediate plugin and output plugins. In other words, there are at least 4 threads in case of a minimal configuration (one input + one output plugin instance).

What do you think is the best practice in this case?

Lukas

@rasaoskuei
Copy link
Author

rasaoskuei commented Nov 23, 2022

Hi, thanks for your description.

My purpose is to terminate the OS context switch (which destroys the CPU cache line and ...). My suggestion is you get a core index in each part of the configuration (optionally) and set the processor thread core affinity. For example, if I used TCP input and JSON Kafka output, I can set <core>CORE_INDEX</core> inside both input and output configurations (this configuration is optional).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants