From nobody Thu May 9 17:19:37 2024 Delivered-To: importer@patchew.org Received-SPF: none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; spf=none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1707242767132874.6803040063494; Tue, 6 Feb 2024 10:06:07 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 996) id 8C36E1CF7; Tue, 6 Feb 2024 13:06:05 -0500 (EST) Received: from lists.libvirt.org.85.43.8.in-addr.arpa (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id E19E51BFA; Tue, 6 Feb 2024 13:04:38 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 996) id 2C3DB18F6; Tue, 6 Feb 2024 13:04:36 -0500 (EST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 11D691BF3 for ; Tue, 6 Feb 2024 13:04:35 -0500 (EST) Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-611-G8-_Da4hOueOCnA8kpmPig-1; Tue, 06 Feb 2024 13:04:33 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E01AB185A780 for ; Tue, 6 Feb 2024 18:04:32 +0000 (UTC) Received: from harajuku.usersys.redhat.com (unknown [10.45.224.47]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 768BC1C060B1 for ; Tue, 6 Feb 2024 18:04:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.4 X-MC-Unique: G8-_Da4hOueOCnA8kpmPig-1 From: Andrea Bolognani To: devel@lists.libvirt.org Subject: [PATCH] docs: Improve documentation for dies and clusters Date: Tue, 6 Feb 2024 19:04:30 +0100 Message-ID: <20240206180430.122839-1-abologna@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Message-ID-Hash: P3LOZHJUUST62IDA4O4OC5GUC6SIMGG4 X-Message-ID-Hash: P3LOZHJUUST62IDA4O4OC5GUC6SIMGG4 X-MailFrom: abologna@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-config-2; header-match-config-3; header-match-devel.lists.libvirt.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.2 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="utf-8"; x-default="true" Content-Transfer-Encoding: quoted-printable X-ZM-MESSAGEID: 1707242768158100001 I've seen examples in the wild of the cluster attribute having non-zero value on x86_64. This is obviously quite confusing, but it's the information that Linux exposes to userspace and we don't really have a way to tell apart a valid die/cluster ID from a dummy one. What ultimately matters is that the underlying assumptions about topology are respected, which they are: in the x86_64 cases that I have analyzed, for example, each "cluster" contained exactly one core, so any program that would use this information to influence guest topology decisions would be unaffected by the additional level showing up in the hierarchy. In an attempt to reduce confusion, document that the value for these attributes is not necessarily going to be zero. Signed-off-by: Andrea Bolognani --- docs/formatcaps.rst | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst index f37532296f..c15d391b63 100644 --- a/docs/formatcaps.rst +++ b/docs/formatcaps.rst @@ -74,14 +74,18 @@ The ```` element consists of the following child= elements: ``die_id`` Identifier for the die the CPU is in. =20 - Note that not all architectures support CPU dies: if the current - architecture doesn't, the value will be 0 for all CPUs. + Note that, while not all architectures support CPU dies, this attribu= te + will always be present in the capabilities XML. If the architecture + doesn't support them, the value will likely be 0 for all CPUs, but it + could also be some other arbitrary value. =20 ``cluster_id`` Identifier for the cluster the CPU is in. =20 - Note that not all architectures support CPU clusters: if the current - architecture doesn't, the value will be 0 for all CPUs. + Note that, while not all architectures support CPU clusters, this + attribute will always be present in the capabilities XML. If the + architecture doesn't support them, the value will likely be 0 for all + CPUs, but it could also be some other arbitrary value. =20 ``core_id`` Identifier for the core the CPU is in. --=20 2.43.0 _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org