public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Peter Krempa <pkrempa@redhat.com>
To: "Michal Prívozník" <mprivozn@redhat.com>
Cc: Stefano Brivio <sbrivio@redhat.com>,
	Libvirt <libvir-list@redhat.com>,
	passt-dev@passt.top, Laine Stump <laine@redhat.com>
Subject: Re: [PATCH 4/4] qemu_passt: Don't let passt fork off
Date: Thu, 16 Feb 2023 10:07:26 +0100	[thread overview]
Message-ID: <Y+3yTgTIrpzPdn2Z@angien.pipo.sk> (raw)
In-Reply-To: <0ab46c27-33aa-35cf-f233-91ca31c26987@redhat.com>

On Thu, Feb 16, 2023 at 09:52:27 +0100, Michal Prívozník wrote:
> On 2/15/23 19:30, Stefano Brivio wrote:
> > On Wed, 15 Feb 2023 18:04:56 +0100
> > Michal Prívozník <mprivozn@redhat.com> wrote:
> >> On 2/15/23 08:50, Laine Stump wrote:

[...]

> > *should* already cover all the cases where libvirt is interested in
> > relaying "early" errors back to the user.
> > 
> > By the way, the one below is pretty much the patch I would have proposed
> > for libvirt. I prepared it earlier today and didn't have a chance to
> > test it yet, it's compile-tested only, and doesn't take cgroups into
> > account (which, it seems, is needed no matter the lifecycle).
> > 
> > So I'm sharing it here as reference (that's how simple I wanted it to
> > be -- minus cgroups), or if it's convenient for you to copy and paste
> > something.
> > 
> 
> This effectively disables placing passt into the CGroup set up for
> emulator thread. And I don't think we want that. Firstly, it makes
> statistics gathering report incorrect values. Secondly, these helper
> processes are "implementation detail" - I mean, users don't really care
> (from accounting POV) whether a task runs in emulator thread inside of
> QEMU or in a separate process. It's still an emulation and as such
> should be accounted for. And also, on NUMA machines we definitely want
> to place passt as close to the emulator as possible (i.e. if emulator
> thread is pinned than helper processes should be pinned too).

Just a side note. We are already at the point where we need
infrastructure to pin/cgroup-place helper processes explicitly similarly
to how we do this for the emulator thread.

Originally the helper processes (e.g. the pr-helper) didn't do much so
it didn't matter much where we placed it.

With processes which do heavy lifting such as network communication or
in case of the qemu-storage-daemon I'm going to implent we are in the
ream of CPU hungry processes where it starts to make sense to dedicate
CPU to it or separate it from the rest.

The approach we pick should be generic enough so that we don't have to
keep re-doing it for each helper process in the future.

I plan to address that with the QSD work, but that will take some time.
If you end up dealing with this sooner, please consider other helper
daemons too.


  reply	other threads:[~2023-02-16  9:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-14 11:51 [PATCH 0/4] qemu_passt: Don't let passt fork off Michal Privoznik
2023-02-14 11:51 ` [PATCH 1/4] Revert "qemu: allow passt to self-daemonize" Michal Privoznik
2023-02-15  7:06   ` Laine Stump
2023-02-14 11:51 ` [PATCH 2/4] qemu_extdevice: Make qemuExtDevicesHasDevice() check def->nets Michal Privoznik
2023-02-15  7:22   ` Laine Stump
2023-02-15 15:23     ` Michal Prívozník
2023-02-14 11:51 ` [PATCH 3/4] qemu_passt: Report error when getting passt PID failed Michal Privoznik
2023-02-15  7:24   ` Laine Stump
2023-02-14 11:51 ` [PATCH 4/4] qemu_passt: Don't let passt fork off Michal Privoznik
2023-02-14 13:02   ` Stefano Brivio
2023-02-14 15:30     ` Michal Prívozník
2023-02-14 16:22       ` Stefano Brivio
2023-02-15  7:50     ` Laine Stump
2023-02-15 17:04       ` Michal Prívozník
2023-02-15 18:22         ` Laine Stump
2023-02-15 18:30         ` Stefano Brivio
2023-02-16  8:52           ` Michal Prívozník
2023-02-16  9:07             ` Peter Krempa [this message]
2023-02-16  9:15             ` Stefano Brivio

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=Y+3yTgTIrpzPdn2Z@angien.pipo.sk \
    --to=pkrempa@redhat.com \
    --cc=laine@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=mprivozn@redhat.com \
    --cc=passt-dev@passt.top \
    --cc=sbrivio@redhat.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).