VM CPU utilization inconsistence

I am attaching an even better example. It appears that you cannot reserve CPU 0 as unraid will ALWAYS use it reserved or not.

Alright so moved my gaming machine way down and ran mover again. It still spiked cpu0 but didn't affect my gaming machine as it was so far down. It appears it is ignoring the cpuset for cpu 0

15 hours ago, Jerky_san said:

Alright so moved my gaming machine way down and ran mover again. It still spiked cpu0 but didn't affect my gaming machine as it was so far down. It appears it is ignoring the cpuset for cpu 0

I asked the question a short while ago about isolating core 0 and what happens. Theoretically unRAID should avoid the core but now that I think about it, I don't think that's the case.

 

And this draws from my experience with isolating cores and then assign the isolated cores to a docker. The docker would end up using ONE of the cores to 100%. A docker is part of what you would call "unRAID" (since it's part of the host). That means isolation actually doesn't prevent the host to use the core. My hypothesis is that a process doesn't know if the core is isolated or not until it starts and checks the isolation list and/or being told "you naughty process, you can't use this". But since it already hold the cores, it will continue to do whatever it wants to do until done like it doesn't care. But it's also prevented from using any other isolated core.

 

So until this is fully resolved, the old advice to keep core 0 (and its SMT sister) free would still be in effect.

 

 

That is complicated by the inconsistency in core pair display in different envi.

My 2990WX shows 0 paired with 1 (so not 0 paired with 32 as yours). Your Zenith X399 must be doing something very different.

38 minutes ago, testdasi said:

I asked the question a short while ago about isolating core 0 and what happens. Theoretically unRAID should avoid the core but now that I think about it, I don't think that's the case.

 

And this draws from my experience with isolating cores and then assign the isolated cores to a docker. The docker would end up using ONE of the cores to 100%. A docker is part of what you would call "unRAID" (since it's part of the host). That means isolation actually doesn't prevent the host to use the core. My hypothesis is that a process doesn't know if the core is isolated or not until it starts and checks the isolation list and/or being told "you naughty process, you can't use this". But since it already hold the cores, it will continue to do whatever it wants to do until done like it doesn't care. But it's also prevented from using any other isolated core.

 

So until this is fully resolved, the old advice to keep core 0 (and its SMT sister) free would still be in effect.

 

 

That is complicated by the inconsistency in core pair display in different envi.

My 2990WX shows 0 paired with 1 (so not 0 paired with 32 as yours). Your Zenith X399 must be doing something very different.

Well this is interesting.. I wonder which board is right? Hope I am not pairing my gaming VM on SMT cores instead of real cores and the like. Guess maybe I should bench and see if it changes..

Shameless plug: I already did some testing in my build topic.

 

 

Edited September 7, 2018 by testdasi

4 minutes ago, testdasi said:

Shameless plug: I already did some testing in my build topic.

 

 

Thanks I'm reading it now and you make me sad... your IOMMU groups are far superior to mine ;-; now wishing I would of bought that board lol

Changed Status to Retest