Re: [PATCH v1 3/7] util: Introduce ThreadContext user-creatable object

[Markus Armbruster]

David Hildenbrand <david@redhat.com> writes:

> On 29.09.22 13:12, Markus Armbruster wrote:
>> David Hildenbrand <david@redhat.com> writes:
>> 
>>> Setting the CPU affinity of QEMU threads is a bit problematic, because
>>> QEMU doesn't always have permissions to set the CPU affinity itself,
>>> for example, with seccomp after initialized by QEMU:
>>>      -sandbox enable=on,resourcecontrol=deny
>>>
>>> While upper layers are already aware how to handl;e CPU affinities for
>>
>> Typo in handle.
>
> Thanks!
>
>> 
>>> long-lived threads like iothreads or vcpu threads, especially short-lived
>>> threads, as used for memory-backend preallocation, are more involved to
>>> handle. These threads are created on demand and upper layers are not even
>>> able to identify and configure them.
>>>
>>> Introduce the concept of a ThreadContext, that is essentially a thread
>>> used for creating new threads. All threads created via that context
>>> thread inherit the configured CPU affinity. Consequently, it's
>>> sufficient to create a ThreadContext and configure it once, and have all
>>> threads created via that ThreadContext inherit the same CPU affinity.
>>>
>>> The CPU affinity of a ThreadContext can be configured two ways:
>>>
>>> (1) Obtaining the thread id via the "thread-id" property and setting the
>>>      CPU affinity manually.
>>>
>>> (2) Setting the "cpu-affinity" property and letting QEMU try set the
>>>      CPU affinity itself. This will fail if QEMU doesn't have permissions
>>>      to do so anymore after seccomp was initialized.
>>
>> Could you provide usage examples?
>
> Patch #7 and the cover letter contain examples. I can add another example 
> here.

Yes, please.

>>> +##
>>> +# @ThreadContextProperties:
>>> +#
>>> +# Properties for thread context objects.
>>> +#
>>> +# @cpu-affinity: the CPU affinity for all threads created in the thread
>>> +#                context (default: QEMU main thread affinity)
>>> +#
>>> +# Since: 7.2
>>> +##
>>> +{ 'struct': 'ThreadContextProperties',
>>> +  'data': { '*cpu-affinity': ['uint16'] } }
>>
>> I understand this is a list of affinities.  What I poor ignorant me
>> doesn't understand is the meaning of the list index.  Or in other words,
>> the list maps some range [0:N] to affinities, but what are the numbers
>> being mapped there?
>
> Assume you have 8 physical CPUs.
>
> $ lscpu
> ...
>
> NUMA:
>   NUMA node(s):          1
>   NUMA node0 CPU(s):     0-7
> ...
>
> You will provide the CPU IDs here, for example as in patch #7 example:
>
> qemu-system-x86_64 -m 1G \
>  -object thread-context,id=tc1,cpu-affinity=3-4 \
>  -object 
> memory-backend-ram,id=pc.ram,size=1G,prealloc=on,prealloc-threads=2,prealloc-context=tc1
>  
> \
>  -machine memory-backend=pc.ram \
>  -S -monitor stdio -sandbox enable=on,resourcecontrol=deny
>
>
> Details about CPU affinities in general can be found in the man page of 
> taskset:
>
> https://man7.org/linux/man-pages/man1/taskset.1.html

Is @cpu-affinity a set of CPU numbers?

> Please let me know how I can further clarify this, that would help, thanks!

What happens when you try to create a thread context object with CPU
affinities on a host system that doesn't support CPU affinities?