Re: [PATCH 4/4] qemu_passt: Don't let passt fork off
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(a)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.