This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Count number of logical processors sharing L2 cache
- From: Florian Weimer <fweimer at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 23 May 2016 16:14:46 +0200
- Subject: Re: [PATCH] Count number of logical processors sharing L2 cache
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOoy2YaQTdyqZpQ3=ytDc5dywNshzHAN2ymN60=L5KwbiA at mail dot gmail dot com> <CAMe9rOoq8MNkX0GvoePQ-C51mfUr2ikrRJgqCZE0CoGoJEmOOw at mail dot gmail dot com> <d4cf36ee-f402-41fe-5108-e072b47f2399 at redhat dot com> <CAMe9rOpUuYboLH9WgyHH4HiBaSBXJ+uB=MPUft2S26N+wYJ9-A at mail dot gmail dot com>
On 05/20/2016 02:13 PM, H.J. Lu wrote:
On Fri, May 20, 2016 at 1:56 AM, Florian Weimer <firstname.lastname@example.org> wrote:
On 05/19/2016 07:50 PM, H.J. Lu wrote:
On Fri, May 13, 2016 at 1:39 PM, H.J. Lu <email@example.com> wrote:
We need count number of available logical processors sharing L2
For Intel processors, when there are both L2 and L3 caches, SMT level
type should be ued to count number of available logical processors
sharing L2 cache. If there is only L2 cache, core level type should
be used to count number of available logical processors sharing L2
cache. Number of available logical processors sharing L2 cache should
be used for non-inclusive L2 and L3 caches.
Is this accounting even relevant anymore, now that cache allocation can be
Can you elaborate?
I'm wondering how this
technology affects what glibc records here. How accurate are the values
glibc computes? Do they need to be recomputed during the life of a
process? Is it still possible to obtain a reasonable approximation of
the over-all CPU cache system from within a userspace process?