From: "Daniel P. Berrangé" <berrange@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Michal Privoznik <mprivozn@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [PATCH] util: NUMA aware memory preallocation
Date: Wed, 11 May 2022 10:34:48 +0100 [thread overview]
Message-ID: <YnuDONrdbMcJT08p@redhat.com> (raw)
In-Reply-To: <8a6b84ed-50bc-8f6e-4b71-7e15247c4ac0@redhat.com>
On Wed, May 11, 2022 at 11:31:23AM +0200, David Hildenbrand wrote:
> >> Long story short, management application has no way of learning
> >> TIDs of allocator threads so it can't make them run NUMA aware.
> >
> > This feels like the key issue. The preallocation threads are
> > invisible to libvirt, regardless of whether we're doing coldplug
> > or hotplug of memory-backends. Indeed the threads are invisible
> > to all of QEMU, except the memory backend code.
> >
> > Conceptually we need 1 or more explicit worker threads, that we
> > can assign CPU affinity to, and then QEMU can place jobs on them.
> > I/O threads serve this role, but limited to blockdev work. We
> > need a generalization of I/O threads, for arbitrary jobs that
> > QEMU might want to farm out to specific numa nodes.
>
> At least the "-object iothread" thingy can already be used for actions
> outside of blockdev. virtio-balloon uses one for free page hinting.
Ah that's good to know, so my idea probably isn't so much work as
I thought it might be.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2022-05-11 9:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-10 6:55 [PATCH] util: NUMA aware memory preallocation Michal Privoznik
2022-05-10 9:12 ` Daniel P. Berrangé
2022-05-10 10:27 ` Dr. David Alan Gilbert
2022-05-11 13:16 ` Michal Prívozník
2022-05-11 14:50 ` David Hildenbrand
2022-05-11 15:08 ` Daniel P. Berrangé
2022-05-11 16:41 ` David Hildenbrand
2022-05-11 8:34 ` Dr. David Alan Gilbert
2022-05-11 9:20 ` Daniel P. Berrangé
2022-05-11 9:19 ` Daniel P. Berrangé
2022-05-11 9:31 ` David Hildenbrand
2022-05-11 9:34 ` Daniel P. Berrangé [this message]
2022-05-11 10:03 ` David Hildenbrand
2022-05-11 10:10 ` Daniel P. Berrangé
2022-05-11 11:07 ` Paolo Bonzini
2022-05-11 16:54 ` Daniel P. Berrangé
2022-05-12 7:41 ` Paolo Bonzini
2022-05-12 8:15 ` Daniel P. Berrangé
2022-06-08 10:34 ` David Hildenbrand
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=YnuDONrdbMcJT08p@redhat.com \
--to=berrange@redhat.com \
--cc=david@redhat.com \
--cc=mprivozn@redhat.com \
--cc=qemu-devel@nongnu.org \
/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.