From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [IPv6:2001:4860:4864:20::35]) by sourceware.org (Postfix) with ESMTPS id C77593893659 for ; Mon, 11 Sep 2023 16:41:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C77593893659 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-1c8d2606fc9so3073828fac.0 for ; Mon, 11 Sep 2023 09:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1694450479; x=1695055279; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=X/elCOeR4tqBz00t/k9OOhLHwegeDd7iZ2YUB/+SeEE=; b=Azb392pI0m8HUWD/ELYE46zxXpaYvpbaMWczjfqTUgb9Af+jdLcdQpN9v0WaLVPq6+ 1+3xXBSQRKIXURBOstqCV/EJiRzRYgAqrOKRONmqUDDxIAQFPCQ1vOmDNTi6d38PkqKu NKUpDzzoJWedCdgqqS5ESFMUf8HfiL+JgQRGgkIA3EHc0KXw1UjAvZV8aYhldTeTUkZ1 dTdcR0bCITAVeZzutVDqCpdSipfjBB2sf9rg+WkHQCLhI52iYT+w5eWJd6In7ZpquHA8 Vfl0oOmyhl24JIWQBfxprCeAjWLGzzZ71fiOKtG94wXWOFPcu7asbZZg9D5w7RdIvMrt urmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694450479; x=1695055279; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=X/elCOeR4tqBz00t/k9OOhLHwegeDd7iZ2YUB/+SeEE=; b=jy2ItbiNEd7cn9Q7c0GRvzszcj72nnERQCCTuHtm6uZZZ5+gFgWSlzGGRn5j7uy85V fd/CN53+5Vd42rS5jIP9yipxpSpwEwde+Nm5dnhfbNf0RY/3VE6qNwa+UXBs5rDKE6Bf r0+QsWXsEA3++aYsk+ZjWElQHqxRmTYDMVQdlqrO8bx3cG5l8Sof7dcMRJbmyqonINsm LcpjH256dxP+4TufhioRTLkDsdK6y5+D9njW+838bBah5dZIrDp70XlrnyXVRogxFbZS bBc5pHJn6GklKVvr3Hkz//Oj+qcohgfYHfZkBx7hk7P5dm1kWVVi8YVLo9vGK8sJ4BnV qrLA== X-Gm-Message-State: AOJu0YzG0E7y8yBlzIpWPwXN4h6DJlg9YsIVqrTK7XRFMMWYfPc1pO+5 H+/n0kuOaT9XnutzHFF5BKCVv04McddqSVIN6HbD5w== X-Google-Smtp-Source: AGHT+IECTpuTHm95MIw0R3p7o/mO2DZF4iOh4ceOky8phvukCn0faguRIPvPU95z2iTlDDT5bnHm1A== X-Received: by 2002:a05:6870:2329:b0:1a6:8911:61a9 with SMTP id w41-20020a056870232900b001a6891161a9mr51187oao.29.1694450479088; Mon, 11 Sep 2023 09:41:19 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:91cb:1977:7e4f:e638:7fad? ([2804:1b3:a7c0:91cb:1977:7e4f:e638:7fad]) by smtp.gmail.com with ESMTPSA id l28-20020a05683004bc00b006b71a4567absm3231037otd.58.2023.09.11.09.41.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Sep 2023 09:41:18 -0700 (PDT) Message-ID: <827ddec8-d5fd-42f0-8401-6cbd161f3b3d@linaro.org> Date: Mon, 11 Sep 2023 13:41:15 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH 2/2] x86: Add generic CPUID data dumper to ld.so --list-diagnostics Content-Language: en-US To: Florian Weimer Cc: libc-alpha@sourceware.org References: <4a77d6294e0023338a8115fad9a3d549c47cae87.1694203757.git.fweimer@redhat.com> <87o7i8ptrf.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <87o7i8ptrf.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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 11/09/23 13:19, Florian Weimer wrote: > * Adhemerval Zanella Netto: > >>> +void >>> +_dl_diagnostics_cpu_kernel (void) >>> +{ >>> +#if !HAS_CPUID >>> + /* CPUID is not supported, so there is nothing to dump. */ >>> + if (__get_cpuid_max (0, 0) == 0) >>> + return; >>> +#endif >> >> I think we don't support __i486__ anymore, so we can just assume HAS_CPUID >> at sysdeps/x86/include/cpu-features.h. > > We still build an i486 variant in build-many-glibcs.py. Indeed. >> Why not use the interfaces to work on cpuset? >> >> if (length_reference > 0) >> { >> int cpu_count = CPU_COUNT_S (length_reference, mask_reference); >> for (int i = 0; i < cpu_count; i++) >> { >> if (CPU_ISSET_S (i, length_reference, mask_reference) >> { >> CPU_SET_S (i, length_reference, mask_request); >> if (INTERNAL_SYSCALL_CALL (sched_setaffinity, 0, >> length_reference, mask_request) == 0) >> { >> _dl_diagnostics_cpuid_collect (&ccd[i & 1]); >> _dl_diagnostics_cpuid_report (processor_index, i, >> &ccd[processor_index & 1], >> &ccd[!(processor_index & 1)]); >> ++processor_index; >> } >> CPU_CLR_S (i, length_reference, mask_request); >> } >> } >> } >> >> I will iterate over the list twice, but I don't think this would really matter >> here. > > I think the macros are somewhat incompatible with direct system calls. > CPU_COUNT_S requires that the tail is zeroed, which the system call > doesn't do. Maybe we can memset the whole thing before the sched_getcpu > system call. I haven't tried if we can directly rebuild > __sched_cpucount for ld.so, either. Afaiu the setsize is exactly to avoid the tail zeroing and to use the syscall return code, isn't? It does not work outside libc because sched_getaffinity does not return the bytes set from the kernel, but it does work with direct syscalls: $ cat > test.c < #include #include #include #include #include int main (int argc, char *argv[]) { size_t cpusetsize = CPU_ALLOC_SIZE (1024); cpu_set_t cpuset[cpusetsize]; memset (cpuset, 0xff, cpusetsize * sizeof (cpu_set_t)); long int sz = syscall (SYS_sched_getaffinity, getpid (), cpusetsize, cpuset); printf ("%ld %d\n", sz, CPU_COUNT_S (sz, cpuset)); return 0; } EOF $ gcc -Wall test.c -o test && ./test 8 24