Re: [PATCH] Count number of logical processors sharing L2 cache

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, May 23, 2016 at 7:14 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 05/20/2016 02:13 PM, H.J. Lu wrote:
>>
>> On Fri, May 20, 2016 at 1:56 AM, Florian Weimer <fweimer@redhat.com>
>> wrote:
>>>
>>> On 05/19/2016 07:50 PM, H.J. Lu wrote:
>>>>
>>>>
>>>> On Fri, May 13, 2016 at 1:39 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> We need count number of available logical processors sharing L2
>>>>> cache.
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>> Any comments?
>>>
>>>
>>>
>>> Is this accounting even relevant anymore, now that cache allocation can
>>> be
>>> tweaked dynamically?
>>
>>
>> Can you elaborate?
>
>
> I'm wondering how this
>
> <https://software.intel.com/en-us/articles/introduction-to-cache-allocation-technology>
>
> 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?
>

CAT applies to a specific thread/process. Cache sizes in glibc are applied
to string/memory functions for all threads/processes.  They both try to avoid
over-using shared cache by a single thread/process.  But they work at
different levels and have different behaviors.  Glibc also uses the cache size
to decide when to use non-temporal store to avoid cache pollution and speed
up writing a large amount of data..

-- 
H.J.