This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Lock elision test results
- From: Andi Kleen <andi at firstfloor dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 05 Jul 2013 18:27:49 -0700
- Subject: Re: Lock elision test results
- References: <20130614102653 dot GA21917 at linux dot vnet dot ibm dot com> <1372767484 dot 22198 dot 4505 dot camel at triegel dot csb> <20130703065355 dot GA4522 at linux dot vnet dot ibm dot com> <1372849432 dot 14172 dot 20 dot camel at triegel dot csb> <20130703120753 dot GA8416 at linux dot vnet dot ibm dot com> <1372857484 dot 14172 dot 195 dot camel at triegel dot csb> <20130704092941 dot GA12864 at linux dot vnet dot ibm dot com> <1372937162 dot 14172 dot 1030 dot camel at triegel dot csb>
Torvald Riegel <triegel@redhat.com> writes:
> We need to model performance in some way
> to be able to find robust tuning parameters,
No, no, the right way is to run lots of work loads (that is real
applications) and see what parameters work best.
Modern caches and CPUs and parallelism of critical sections
are far too complex to model in simple ways.
> at the aborts; it seems that for z at least, the critical section length
> should also be considered.
I don't know about z, but in TSX the program doesn't know the critical
section length (without expensive extra instrumentation). Only profilers
know.
-Andi
--
ak@linux.intel.com -- Speaking for myself only