From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) by sourceware.org (Postfix) with ESMTPS id CDE893858D38 for ; Mon, 11 Sep 2023 16:16:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CDE893858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-1c0fcbf7ae4so3544773fac.0 for ; Mon, 11 Sep 2023 09:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694449010; x=1695053810; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=chGxfCyvrfVETdlWXwoZA8qQxgUnVbcbWb0+vMUm/HA=; b=frp+I3z0qPx1rfCdrb+1ovH+zaNF3pbcRqymsHSxIa7DaAzKIAsg+K81sQ8RemurGR 4khuJnvLyNclaxsShId7Um+91RJiQvuizH1xiePEnQ80gTjx3PtsFhWtEMP21Yv/dGAH 8HQTvW9RPjrb55RbgBWfIsYRF5C8yizhHQf7yOsERX6m5OqtWDckrfA5IBoO5I10zecw 3Eo9YJRPeGcI05HQwiJW5jSYjiwUejTbvLLayYJKKATieZXzdyeV7o8U9pNamRxw8AyP RNaoqgFC8TATiP06nc8gZ19e8f4mOa35jyWvilFSBoD8a9mj0jJGPvLv3HXxjuAR+eNs ipnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694449010; x=1695053810; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=chGxfCyvrfVETdlWXwoZA8qQxgUnVbcbWb0+vMUm/HA=; b=T7OZIYt5UKULSUiXIsMizcQfFN9JZ+YJVVCqchExIz1XheSWi09UFPUO7DrZHgU6oo 3LxIl5Qxt2OGUXSTtXKEKn3ZRQ3KBKRoO50T8nqM7zoB+7G3Jgq2u8xbeVM69rwt4qsC Hev4ULtJqUIPry+eS0+9/GfwyYKWv4BO3vHP8D9B/C6Rtrysw74V9lZFQRevFfEtCjuS EU3+68/2iunWkno/ph3XYVJKFvpl9Vy1mcvni63Yu59IdixGwWxkvImcu+MJFVtfktVP 477jyEjUsZ/ILa+X/eDpFgmnaFe984NNVgbMK3fDzLcGSDNwep3hSudfe88AsAlMKYqj Ctew== X-Gm-Message-State: AOJu0YzlBWmFLc6kvx76X4wi6/vpZEHCPjMRdUA0GHM4lR+Qv9f4dXX5 XN2hIn1Knv6ihNqPPT1fXAfDeDi88WPoAS0SG0Q= X-Google-Smtp-Source: AGHT+IE9SSjoZOUHMrr2l7TwoRlF1XTSpN9KobEhx6qxhnjpFSE67GHgWgm/YxsUnEbQoCaXt9OLRpoDPPsvMh91ATk= X-Received: by 2002:a05:6870:b289:b0:1bb:b9d6:a879 with SMTP id c9-20020a056870b28900b001bbb9d6a879mr13207300oao.38.1694449010048; Mon, 11 Sep 2023 09:16:50 -0700 (PDT) MIME-Version: 1.0 References: <4a77d6294e0023338a8115fad9a3d549c47cae87.1694203757.git.fweimer@redhat.com> <871qf549sa.fsf@oldenburg.str.redhat.com> In-Reply-To: <871qf549sa.fsf@oldenburg.str.redhat.com> From: Noah Goldstein Date: Mon, 11 Sep 2023 11:16:33 -0500 Message-ID: Subject: Re: [PATCH 2/2] x86: Add generic CPUID data dumper to ld.so --list-diagnostics To: Florian Weimer Cc: libc-alpha@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sun, Sep 10, 2023 at 11:24=E2=80=AFPM Florian Weimer wrote: > > * Noah Goldstein: > > > On Fri, Sep 8, 2023 at 3:10=E2=80=AFPM Florian Weimer wrote: > >> > >> This is surprisingly difficult to implement if the goal is to produce > >> reasonably sized output. With the current approaches to output > >> compression (suppressing zeros and repeated results between CPUs, > >> folding ranges of identical subleaves, dealing with the %ecx > >> reflection issue), the output is less than 600 KiB even for systems > >> with 256 threads. > >> > > Maybe should just output a complete json? > > JSON cannot directly represent 64-bit integers, so it would need some > custom transformation for other parts of the --list-diagnostics output. > > > Then users can pretty easily write scripts to extract the exact informa= tion > > they are after. Or or the dumper can be extended in the future to let > > the user specify fields/values to dump so it can be configured to be mo= re > > reasonable? > > I'm not sure what is unreasonable about the current implementation? I > complained about how hard it is getting the data and distilling it into > something that is not a gigantic data blob. > > To be clear, without only trivial zero-values suppression, brute-force > enumeration (cutting off at 512 subleaves) results in roughly 8 KiB of > raw data per *CPU*. It's even larger for recent CPUs which have more of > the funny ECX behavior (where unsupported subleaves do not come back as > zero). Maybe I misunderstand but the commit message is saying a 256 core system dumps 600KB? If so, that seems like a lot for a person to just grok hence why I'd favor a standardized format. If JSON isn't really feasible for technical reasons, however, so be it. > > Thanks, > Florian >