This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, May 31, 2016 at 7:01 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 05/24/2016 05:35 PM, H.J. Lu wrote:
>> CAT dedicates part of L3 cache to certain processor or process so
>> that L3 cache is always available to them.  Glibc tries not to take all
>> L3 cache in memcpy/memset so thar L3 cache is available for other
>> operations within the same process as well as to other processor/process.
>> CAT and glibc work at different angels.  There is no direct conflict between
>> CAT and glibc.  At the moment,  I am not sure if CAT-aware glibc will
>> improve performance.
>
> What do you mean by "no direct conflict?"
>
> If glibc tuns its own algorithms to use 1/4 of L3, but CAT has only
> allocated 1/5 of L3 to that process, then glibc's algoirthms, whose
> intent was to use a small amount of L3 are now using *more* L3 than
> the entire process has and that could impact performance?

Cache sizes are only used for instructions selections in
string/memory functions, which don't use cache directly.
Glibc has NO control whatsoever on how much cache
string/memory functions use.

> Did I miss something?
>
> There could be opportunities for incorrect tunings if glibc is not
> CAT-aware?
>

Since CAT can change at any time during the life of a process,
checking CAT inside glibc isn't very practical.

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]