Info Process Lasso limitation when trying to isolate CPU core performance

[igor_kavinski]

So I tried Process Lasso today on my 245KF and discovered something interesting when trying to isolate Skymont performance with it.

It works and the single enabled Lion Cove barely shows any activity IF:

1) The application doesn't outright ignore process affinity.

2) The application has a single process and no child processes. If it has child processes, then you have to look at the CPU utilization of the child processes to see which one's process affinity to mess with. And it may turn out that the child process ignores process affinity.

3) The process is not doing anything related to file I/O. Yes, basically any process concerned with writing to file(s) will most likely fail to keep itself from touching the core you've forbidden for it.

Noticed No.3 happening with Rapydmark and Handbrake. The former touched the lone Lion Cove core in the file based subtests and Handbrake was unable to ignore the Lion Cove core as well. y-cruncher straight away ignored process affinity, maybe because it's writing to a validation file?

V-ray 6 benchmark has a child render process so you need to set affinity on that particular process. Doing it on the parent process has no effect on the child process.

Anyway, hope these findings are useful to current and future x86/WinARM CPU core performance hobbyists

EDIT: @StefanR5R was instrumental in solving the mystery and now I've managed to isolate the E-cores for workload execution in both Handbrake and y-cruncher!

 

[Hulk]

Good info Igor. I also have found E cores extremely difficult to isolate. There is a reason why Intel does not allow all P cores to be disabled in the BIOS. Whatever it is I think it has to do with that lone P cores always working its way into the mix. At least one P core is necessary for something.

 

[StefanR5R]

Disclaimer: I don't know much about Windows and never used Process Lasso. I did however occasionally use and modify a PowerShell script which sets process affinities. I use Linux more and know it better than Windows.
_ _ _ _ _ _ _ _

A) I would expect that
– if a CPU affinity mask was set on a process, and after that the process spawns child processes, that the children either inherit the parent's affinity mask 1:1 or, if the parent process for some reason sets a specific affinity mask for its children, then that can only be a subset of the parent's affinity;
– respective elevated administrative privileges would be needed to widen a process's affinity mask (as opposed to set a narrower one; IOW add bits as opposed to clear bits from the affinity mask).
But maybe I am mistaken about Windows' policies in this regard.

B) If a process is multithreaded, maybe the user needs to take special precaution to set the affinity to all threads, not just of e.g. the initial (main) thread of the process?

C)

basically any process concerned with writing to file(s) will most likely fail to keep itself from touching the core you've forbidden for it.

I/O involves kernel calls, activity in the kernel's interrupt handlers, and more. Especially the interrupt handlers don't run with a CPU affinity which was set for any of the I/O consuming userspace processes.

 

[igor_kavinski]

I/O involves kernel calls, activity in the kernel's interrupt handlers, and more. Especially the interrupt handlers don't run with a CPU affinity which was set for any of the I/O consuming userspace processes.

It wasn't just the kernel using that forbidden core. It was used almost 100% so a compute intensive thread is assigned to that core and affinity is ignored.

 

[StefanR5R]

How did you monitor what is going on?
Try resmon if you haven't already. Although a 3rd party tool may be called for at this point, but I don't know any for the purpose.

 

[igor_kavinski]

How did you monitor what is going on?

Task Manager CPU utilization graph. Will check resmon and post a screenshot if possible.

 

[StefanR5R]

PS:
I suspect the problem is not that CPU affinities are "ignored" (on Linux, they are mandatory; it would surprise me if they were voluntary on Windows NT++) but that they rather are not applied in the desired way.

 

[igor_kavinski]

PS:
I suspect the problem is not that CPU affinities are "ignored" (on Linux, they are mandatory; it would surprise me if they were voluntary on Windows NT++) but that they rather are not applied in the desired way.

That mandatory part got me thinking, hey, this is serious stuff if the Linux kernel takes it so seriously. So checked out the Process Lasso FAQ and there was this section about using "Forced" mode which would slap any processes back into submission should they try to change the affinity mid execution. That and the "Always" setting worked together to make it happen.

THANK YOU for helping to solve this mystery!

Still doesn't work on Rapydmark (some darn pesky subtests it's got!) but I guess it's an extremely rare case.

 

[igor_kavinski]

This is the thing that was so difficult to do before but now piece of cake: https://forums.anandtech.com/threads/arrow-lake-builders-thread.2622775/post-41388470

Affinity was set on the "Kurumi" child process.