From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 3AC3E5A0082 for ; Thu, 16 Feb 2023 10:07:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676538455; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xFr63DmhgVwnu/X1/3+VkxtxdCff2xJ+uyQJ1LvVokM=; b=BVc9bLgzzkCR1jnKpi0/JwOHnf4xU9orfyRH+Z4QyLfD0nC9BNtR/AKEzMdirUF87ich2o xfEXdenm6bMjn3ko/qjBZg3gE6VvIJ/jZThkEdZ0Bl9xcSaZtMFJEVPttI60kTgc0OwpIl 0+xjT8O7K9f2obvK+THvNAqtyfK7aKM= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-6-mC_kJuRSP166sLSkmdxA2w-1; Thu, 16 Feb 2023 04:07:31 -0500 X-MC-Unique: mC_kJuRSP166sLSkmdxA2w-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 31FCB85CCE0 for ; Thu, 16 Feb 2023 09:07:31 +0000 (UTC) Received: from angien.pipo.sk (ovpn-208-8.brq.redhat.com [10.40.208.8]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5E3F61121314; Thu, 16 Feb 2023 09:07:29 +0000 (UTC) Date: Thu, 16 Feb 2023 10:07:26 +0100 From: Peter Krempa To: Michal =?iso-8859-1?B?UHLtdm96bu1r?= Subject: Re: [PATCH 4/4] qemu_passt: Don't let passt fork off Message-ID: References: <5abfc412e4692a38e980c8dc600e1bfbd03ddcfd.1676374699.git.mprivozn@redhat.com> <20230214140253.49bbc13a@elisabeth> <90dbb5f3-7b3f-893c-ca32-a7653eb486c6@redhat.com> <7cbc3713-9d51-2950-2a3c-ae90928b83b6@redhat.com> <20230215193020.4af13f54@elisabeth> <0ab46c27-33aa-35cf-f233-91ca31c26987@redhat.com> MIME-Version: 1.0 In-Reply-To: <0ab46c27-33aa-35cf-f233-91ca31c26987@redhat.com> User-Agent: Mutt/2.2.9 (2022-11-12) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-MailFrom: pkrempa@redhat.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation Message-ID-Hash: JZA5FHSQOVJCTS3APHRBZCIAM3M5SEKC X-Message-ID-Hash: JZA5FHSQOVJCTS3APHRBZCIAM3M5SEKC X-Mailman-Approved-At: Thu, 16 Feb 2023 18:44:36 +0100 CC: Stefano Brivio , Libvirt , passt-dev@passt.top, Laine Stump X-Mailman-Version: 3.3.3 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, Feb 16, 2023 at 09:52:27 +0100, Michal Pr=EDvozn=EDk wrote: > On 2/15/23 19:30, Stefano Brivio wrote: > > On Wed, 15 Feb 2023 18:04:56 +0100 > > Michal Pr=EDvozn=EDk 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. > >=20 > > 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). > >=20 > > 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. > >=20 >=20 > 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.