>I know I've heard both good and bad things about lmbench, but are these
>numbers fairly accurate? Looking at the context switch code in
>proc-sa110.S shows comments pertaining to flushing the cache being
>horribly slow, which I'm guessing is because to flush it you have to
>read 16KB of data from the cache flush area.
Mostly I think lmbench is telling the truth. Some of the delay will be due to
flushing the cache; on the EBSA-285 I'd expect that to be about 70us or so.
I don't know where the rest of the slowdown is coming from but it would be
interesting to find out. I usually get 2-way context switch times of about
160us on my netwinder, for what that's worth.
>Have there been many changes to the context switching code in 2.3 at
>all that attempt to speed this up? Thanks.
No. There's nothing can be done about the cache, other than making some
effort to avoid flushing it when possible. This helps a bit with the
situation where you have one or more kernel threads (nfsd, kflushd, swapper or
whatever) being scheduled a lot, and also for multithreaded user applications,
but not a lot for general multitasking. It might be possible to avoid some of
the other latency but I don't know of anybody who's actively looking into it
right now. I did do a bit of work a month or so back to cut down on cache
flushing under other circumstances, which helps with things like lat_proc, but
not context switching as such.
p.
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
