Question - CPU Affinity Limit w/Upper Range Using Wildcard

Started by nah1982, December 18, 2020, 11:37:57 PM

Previous topic - Next topic

nah1982

Hello and thank you for any help.

Is there a way to limit CPU Affinities in a wildcard manner, e.g. instead of having 0 - 15 normal, which I limit most processes to 2 - 15, I limit them to 2 to * such that they can use any cores from 2 onward.

I ask, because as a Threadripper user, sometimes I need to disable cores for certain things, and when I do it causes Bitsum to hangup on processes I've previously limited to 2 to 31 when all cores are running, but now only 0 to 15 are running. It's constantly trying to enforce the 2 - 32, but only 0 - 15 are active, so it's erroring out, and I have to disable the engine to stop hangups. I'd like it to dynamically adjust the top end core #, but leave the low end e.g. 2, intact so as that # shifts I can leave the engine running.

Thanks again if you can help.

Sincerely,
Nathaniel

Jeremy Collake

Enabling the CPU affinity rules to properly function after changes to the system CPU core count is under consideration (issue #777).

Allowing 0-* type rules is an option.

I don't have any ETA to give you, but it is on the radar. I'll post here when progress occurs.

Thanks for the feedback!
Software Engineer. Bitsum LLC.

nah1982

Quote from: Jeremy Collake on December 19, 2020, 09:49:06 AM
Enabling the CPU affinity rules to properly function after changes to the system CPU core count is under consideration (issue #777).

Allowing 0-* type rules is an option.

I don't have any ETA to give you, but it is on the radar. I'll post here when progress occurs.

Thanks for the feedback!

Understood; thanks for the feedback!

I'm not as advanced a use case as some; it does a great job, and I set and forget it until something goes wrong, and this would just continue that theme for me. :)

Otherwise, love the product; bought it for other family members as well and have recommended to friends/co-workers, so keep up the great work!

Thanks.

Sincerely,
Nathaniel

nah1982

Quote from: Jeremy Collake on December 19, 2020, 09:49:06 AM
Enabling the CPU affinity rules to properly function after changes to the system CPU core count is under consideration (issue #777).

Allowing 0-* type rules is an option.

I don't have any ETA to give you, but it is on the radar. I'll post here when progress occurs.

Thanks for the feedback!

An additional feature potential is the exclusion of CPUs explicitly vs. selecting CPUs explicitly to run on; eliminates the need for N -> *

Jeremy Collake

An inverted CPU affinity is an interesting idea.

However, to avoid complexity, probably I will just strip the unavailable CPUs from the bitmask. Then suggest use of named configuration profiles for dramatic changes to the system config like this.

I will try to get to this soon so we can trial its efficacy.
Software Engineer. Bitsum LLC.

Jeremy Collake

#5
I went ahead and made this change (strip unavailable CPUs from CPU affinities prior to applying them) to v9.8.8.27 beta.

If you try it, let me know how it treats you. I believe it is the simplest and most effective way to handle this scenario. It is effectively the same as n-*.
Software Engineer. Bitsum LLC.

nah1982

Quote from: Jeremy Collake on December 21, 2020, 09:43:02 AM
I went ahead and made this change (strip unavailable CPUs from CPU affinities prior to applying them) to v9.8.8.27 beta.

If you try it, let me know how it treats you. I believe it is the simplest and most effective way to handle this scenario. It is effectively the same as n-*.

Wow! Wasn't expecting it to be tackled for a while.  :)

Just downloaded and installed / testing. So it appears to stop erroring out, however, it still is attempting to apply the rules constantly, like it's detecting they're still not set to the original rule vs. taking the rule and only applying it up to the maximum available.  :-\

The overall usage of it's attempt to do so seems to have dropped e.g. little to no impact; it's just still logging those attempts.

Otherwise, I'll continue to test and let you know if I encounter anything else. Thanks!

Sincerely,
Nathaniel

Jeremy Collake

Quote..it still is attempting to apply the rules constantly, like it's detecting they're still not set to the original rule vs. taking the rule and only applying it up to the maximum available.

Thank you for that! Please hold for further work.
Software Engineer. Bitsum LLC.

Jeremy Collake

Software Engineer. Bitsum LLC.

nah1982

Quote from: Jeremy Collake on December 27, 2020, 01:08:35 PM
Give 9.8.8.29 beta a spin. Let me know how it goes!

Thanks for the follow-up! I'm on 9.8.8.31 now. It still seems to be attempting, but only once, and then stops, accepting the assignment of 2-15 vs 2-31. Less logging for sure, and less hitching on that. Has been working like a charm all day. Unless it reverts in the future, this seems to be functioning as intended. Thanks again so much for looking at this so quickly!

Sincerely,
Nathaniel