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 1/2] Single thread optimization for malloc atomics


On Wed, Apr 30, 2014 at 11:25:36AM -0300, Adhemerval Zanella wrote:
> On 30-04-2014 11:18, OndÅej BÃlka wrote:
> > On Wed, Apr 30, 2014 at 10:57:07AM -0300, Adhemerval Zanella wrote:
> >> This patch adds a single-thread optimization for malloc atomic usage to
> >> first check if process is single-thread (ST) and if so use normal
> >> load/store instead of atomic instructions.
> >>
> > How fast is tls on power? When we add a per-thread cache as I suggested
> > then it would have most of time same performance as singlethread, with
> > overhead one tls variable access per malloc call.
> >
> The question is subtle, you mean compared to what?  Others memory allocators
> that per-thread cache shows good performance using TLS.
> 
> Anyway, *now* this lock is an issue that has being circumvented in a
> arch-specific way (at least for x86_64).  I know that is not the best way
> to fix all current malloc issues, but it something we can optimize for
> single-thread that has minor code impacts.

Compared to single thread case. At start of malloc you could just get a
pointer to structure and rest of code would be identical to
single-thread one using that structure.


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