All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: qemu-devel@nongnu.org, "Michal Privoznik" <mprivozn@redhat.com>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	"Eric Blake" <eblake@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Stefan Weil" <sw@weilnetz.de>
Subject: Re: [PATCH v2 3/7] util: Introduce ThreadContext user-creatable object
Date: Wed, 12 Oct 2022 12:23:20 +0200	[thread overview]
Message-ID: <878rlle3xj.fsf@pond.sub.org> (raw)
In-Reply-To: <ee441feb-3293-efe7-e273-3d28910a0b19@redhat.com> (David Hildenbrand's message of "Wed, 12 Oct 2022 10:19:11 +0200")

David Hildenbrand <david@redhat.com> writes:

> Thanks Markus!
>
>> I just tested again, and get the same result as you.  I figure my
>> previous test was with the complete series.
>> PATCH 5 appears to make it work.  Suggest to say something like "The
>> commit after next will make this work".
>
> I'll phrase it like " We'll wire this up next to make it work."

Works for me!

> [...]
>
>>>> So, when a thread is created, its affinity comes from its thread context
>>>> (if any).  When I later change the context's affinity, it does *not*
>>>> affect existing threads, only future ones.  Correct?
>>>
>>> Yes, that's the current state.
>> 
>> Thanks!
>
> I'm adding
>
> "Note that the CPU affinity of previously created threads will not get adjusted."
>
> and
>
> "In general, the interface behaves like pthread_setaffinity_np(): host CPU numbers that are currently not available are ignored; only host CPU 
> numbers that are impossible with the current kernel will fail. If the list of host CPU numbers does not include a single CPU that is 
> available, setting the CPU affinity will fail."

This is one of the reasons why reviewing your work is such a pleasure:
not only do you answer my questions with clarity and patience, you
proactively improve your patches before I can even think to ask.

Thank you!



  reply	other threads:[~2022-10-12 10:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-10  9:11 [PATCH v2 0/7] hostmem: NUMA-aware memory preallocation using ThreadContext David Hildenbrand
2022-10-10  9:11 ` [PATCH v2 1/7] util: Cleanup and rename os_mem_prealloc() David Hildenbrand
2022-10-10  9:11 ` [PATCH v2 2/7] util: Introduce qemu_thread_set_affinity() and qemu_thread_get_affinity() David Hildenbrand
2022-10-10  9:11 ` [PATCH v2 3/7] util: Introduce ThreadContext user-creatable object David Hildenbrand
2022-10-11  5:47   ` Markus Armbruster
2022-10-11  7:53     ` David Hildenbrand
2022-10-12  8:02       ` Markus Armbruster
2022-10-12  8:19         ` David Hildenbrand
2022-10-12 10:23           ` Markus Armbruster [this message]
2022-10-12 12:27             ` David Hildenbrand
2022-10-10  9:11 ` [PATCH v2 4/7] util: Add write-only "node-affinity" property for ThreadContext David Hildenbrand
2022-10-11  6:03   ` Markus Armbruster
2022-10-11  7:34     ` David Hildenbrand
2022-10-12  8:03       ` Markus Armbruster
2022-10-12  8:26         ` David Hildenbrand
2022-10-10  9:11 ` [PATCH v2 5/7] util: Make qemu_prealloc_mem() optionally consume a ThreadContext David Hildenbrand
2022-10-10  9:11 ` [PATCH v2 6/7] hostmem: Allow for specifying a ThreadContext for preallocation David Hildenbrand
2022-10-10  9:11 ` [PATCH v2 7/7] vl: Allow ThreadContext objects to be created before the sandbox option David Hildenbrand
2022-10-10 10:40 ` [PATCH v2 0/7] hostmem: NUMA-aware memory preallocation using ThreadContext Dr. David Alan Gilbert
2022-10-10 11:18   ` David Hildenbrand
2022-10-11  9:02     ` Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878rlle3xj.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=mprivozn@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=sw@weilnetz.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.