Exact steps for others to reproduce the error
Turn on blender. Manually set processor affinity to use only some of the processors. Press render. Wait until it start rendering tiles. After start of tile rendering affinity is reset to use all processors.
Eevee and Workbench do not have this issue. Only Cycles.

Our current goal is to give best performance for artist on a machine with lots of cores (> 64) and on CPUs with non-trivial topology (i.e. Threadripper2 and certain configurations of EPYC computers). Currently this implies following aspects:

Making sure main Blender thread and Cycles synchronization thread are scheduled to a NUMA node with direct memory access.

When Cycles is configured to use all threads, we need to make sure render threads are using all NUMA nodes from all CPU groups (this is the only way we can scale to over 64 threads on Windows, i.e.).

When Cycles is configured to use few threads, we need to make sure those have direct memory access as well (there is still possible tweak logic, to allow occupying two fast NUMA nodes on Threadripper2 processors).

@Brecht Van Lommel (brecht), you can query current thread affinity, but you can not distinguish between it being set by an OS or tweaked by a user. This isn't really a bug, but there might be something we can do to support specific usecases better (but maybe we'd need to introduce some command line argument for that =/).

Ability to manually control affinity is crucial if one needs to use the PC for other tasks while also waiting for some long render to finish. In some cases, setting CPU priority to low is not enough to free up enough resources, fast enough so that other software does not lag.

Defaulting to no affinity and full CPU usage is of course fine, but it should happen only once, at the Blender launch. It should not be reset on every single render. That's just disrespectful, as it ignores user's conscious choice.

Simply keep doing what you are doing, but do not set it on each render, just once when Blender session starts. Only those who go all the way to change the affinity manually in the task manager could ever encounter performance issues then.

why not control it with the options in the performance section of blender? set it to use a single thread and off you go, leaving it on auto (which in your case is probably 12) and limiting affinity manually to a single core will lead to excessive context switches ruining performance.

Just a follow up. I contribute my Threadripper to a community renderfarm, but don't actually use Blender/Cycles myself. I found this issue on google because I noticed weird things on htop.

It appears some projects are submitted to the render farm set to use a specific number of threads (presumably under the Cycles performance tab). If this number is small, then it was triggering all threads to set their affinity to 0-15. Blender is launched with -t 64 so there were 64 threads all limited to cores 0-15. It seems the command line argument didn't interact ideally.

I see there's been a commit (and we run an outdated nightly so I will workaround this) but will the -t command line argument and the cycles settings in the .blend file work together correctly in the current version?

Hi,
Any further development on this task?
I am facing the same issue - When cycles is rendering, it resets to use all cores even if the affinity is set to not use all the cores.
When dealing with larger files, operating systems are rendered useless to use it for any other task, unless you can set the affinity of the blender to not use few cores.
It helps a lot, crucial for multitasking.