Re: Etch for ARM / Netwinder: where is NPTL support?
On Fri, May 11, 2007 at 02:49:53PM +0100, Martin Guy wrote:
> >> I can try and dig up the mail thread if that'll help
> >That would definitely help, please do.
>
> I have the erudite:
>
> Michael K Edwards 06/12/2006 Re: More ARM binutils fuckage
>
> >>>You wouldn't happen to have benchmarked a thread-intensive load o>n
> >>>your hardware with and without NPTL, would you? I would expect the
> >>>gain to be significant from not blowing MMU context on every thread
> >>>switch, but I haven't seen hard numbers on ARM.
> >>
> >>Why would LinuxThreads 'blow MMU context on every thread switch'?>
> >
> >TLB and cache impacts of context switching on (some) ARMs are
> >discussed in
> >http://www.ertos.nicta.com.au/publications/papers/Wiggins_TUH_03.ps.gz.
I don't see how the existence of a paper which discusses TLB and cache
effects during context switching on ARM machines somehow proves the
hypothesis that LinuxThreads 'blows MMU context on every thread switch'.
> >I don't know the details of the implementation too well, but my
> >understanding is:
> >
> >1: LinuxThreads was user managed threads, so any thread switch did not
> >require a process switch, and was handled by user-level.
This is bull.
> > Because of this thread switch did not require a TLB flush or
> > cache flush.
This is partly bull.
In LinuxThreads, as in NPTL, thread switching indeed does not require
a TLB flush or cache flush, but for a different reason than the one
given above.
> >2: NTPL, every thread is a process. A process switch on ARM requires a
> >TLB and full cache flush due to the virtual caches on ARM. Unless NTPL
> >has some special logic to handle the case when it switches between two
> >threads in the same process it will be very expensive contexting
> >switching threads on a native Linux.[*]
This is bull as well.
As the gentlemen said ("I don't know the details of the implementation
too well"), it was just his uninformed understanding, and should not
have been taken as gospel.
Reply to: