Re: EABI and ARM context switching

[Ben Leslie <benno at ok-labs dot com>]

On Tue Dec 05, 2006 at 20:25:02 -0800, Michael K. Edwards wrote:
>>> You wouldn't happen to have benchmarked a thread-intensive load on
>>> 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.
> This is not my area of expertise and I don't know to what extent
>newer ARM and XScale cores or the current mechanisms of TLS/NPTL
>improve the situation.  I have copied kenge-users@ertos.nicta.com.au,
>which appears to be a good way to reach people who have studied this
>problem closely.

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. Because of
this thread switch did not require a TLB flush or cache flush.

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.[*]

On ARM11 based chips this problems is less of an issue, but will still
require careful cache management to avoid aliasing problems.

Cheers,

Benno

[*] It could well be that there is special logic here, I ahven't looked a the
NPTL stuff in detail.

--
For unsubscribe information see http://sourceware.org/lists.html#faq