Re: cpuset/affinity interfaces and TSX lock elision in musl

[Rob Landley <rob@landley.net>]

On 05/17/2013 02:41:18 AM, Daniel Cegiełka wrote:
> Rich, Rob - thanks for the information. This is functionality that
> sooner or later, but it is worth to add to the musl.
> 
> >> 2) The upcoming glibc will have support for TSX lock elision.
> >>
> >>  
> http://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions
> >>
> >> http://lwn.net/Articles/534761/
> >>
> >> Are there any outlook that we can support TSX lock elision in musl?
> >
> > I was involved in the discussions about lock elision on the glibc
> > mailing list, and from what I could gather, it's a pain to implement
> > and whether it brings you any benefit is questionable.
> 
> There is currently no hardware support, so the tests were done in the
> emulator. It's too early to say there's is no performance gain.
> 
> > Before making
> > any decision, I think we should wait to see some performance  
> figures.
> 
> musl is described as libc for embedded systems (raspberry pi, small
> routers, mobile etc.). Summing up: low-end hardware.

Where is it described that way? That wasn't my impression: it was a  
simple generic C library for Linux and Android. We should be able to  
build desktops with it just fine.

> I think musl is
> the ideal solution for high-end HPC servers etc., so that's why we
> should support innovative solutions (like TSX lock elision).

HPC and embedded are closer to each other than either is to the  
desktop. They race to completion, we race to quiescence on underpowered  
hardware; neither has persistent processes but more of a batch  
mentality. We keep power consumption down to extend battery life, they  
keep power consumption down because heat dissipation costs more than  
the hardware...

Right now I'm in month 4 of a 6 month contract at Cray, the  
supercomputer company. (No, not the one SGI bought: it split in two  
when Seymour Cray retired and they gave him a $100 million research lab  
as a retirement present. The half SGI _didn't_ buy expanded back into  
the space and is again supercomputing in the big leagues.)

> We may
> also ask manufacturers (such as Intel) for help with optimization
> (they really help with glibc and gcc).

Worry about target-specific optimization after 1.0. Until then it's  
premature optimization. Right now target-independent optimization seems  
more interesting. (To me, anyway.)

Rob