Re: [Xen-devel] [PATCH 13/60] xen/sched: move some per-vcpu items to struct sched_unit

[Jan Beulich <JBeulich@xxxxxxxx>]

On 02.07.2019 10:21, Dario Faggioli wrote:
> On Tue, 2019-07-02 at 07:54 +0000, Jan Beulich wrote:
>> On 02.07.2019 08:30, Juergen Gross wrote:
>>> On 01.07.19 17:46, Jan Beulich wrote:
>>>>
>>>> Hmm, that's indeed what I was deducing, but how will we sell this
>>>> to people actually fiddling with vCPU affinities? I foresee
>>>> getting
>>>> bug reports that the respective xl command(s) do(es)n't do
>>>> anymore
>>>> what it used to do.
>>>
>>> The new behavior must be documented, sure.
>>
>> Documentation is just one aspect. Often enough people only read docs
>> when wanting to introduce new functionality, which I consider a fair
>> model. Such people will be caught by surprise that the pinning
>> behavior does not work the same way anymore.
>>
> That is indeed the case, and we need to think about how to address it,
> I agree.
> 
>> And again - if someone pins every vCPU to a single pCPU, that last
>> such pinning operation will be what takes long term effect. Aiui all
>> vCPU-s in the unit will then be pinned to that one pCPU, i.e.
>> they'll either all compete for the one pCPU's time, or only one of
>> them will ever get scheduled.
>>
> I'm not sure I'm getting this. On an, say, SMT system, with 4 threads
> per core, a unit is 4 vCPUs and a pCPU is 4 threads.

No, the meaning of pCPU is a single thread of a single core. I.e.
what is represented by a single cpumask_t bit.

Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel