[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v1 3/7] util: Introduce ThreadContext user-creatable object
From: |
Markus Armbruster |
Subject: |
Re: [PATCH v1 3/7] util: Introduce ThreadContext user-creatable object |
Date: |
Thu, 29 Sep 2022 14:25:53 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
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?
[PATCH v1 4/7] util: Add write-only "node-affinity" property for ThreadContext, David Hildenbrand, 2022/09/28
[PATCH v1 5/7] util: Make qemu_prealloc_mem() optionally consume a ThreadContext, David Hildenbrand, 2022/09/28
[PATCH v1 6/7] hostmem: Allow for specifying a ThreadContext for preallocation, David Hildenbrand, 2022/09/28
[PATCH v1 7/7] vl: Allow ThreadContext objects to be created before the sandbox option, David Hildenbrand, 2022/09/28