Lars Michael <lh_post <at> yahoo.com> writes:
> At the same time we noticed (by using strace) that there is an excessive and
continously sequence of system
> calls at normal program execusion:
>
> 333 (__NR_GET_THREAD_AREA), and 335 (__NR_ATOMIC_CMPXCHG_32)
Yes, that is in fact normal. If you stop using programs (and libraries)
that use TLS (thread-local storage) and atomics, you’ll notice a massive
speedup as these syscalls will no longer be issued.
The only way out of this is an ABI breakage, with at least
* set one CPU register aside for the TLS base
* add a VDSO or some other kind of page for “fast syscalls”,
to optimise away the need for cmpxchg to call into the
kernel (if possible), and maybe speed up e.g. gettimeofday
* bump time_t to 64 bit (pet peeve of mine)
* … maybe others? I’m not a Linux kernel coder.
bye,
//mirabilos
PS: Does strace by now know about these two syscalls,
and possibly filter them out? Does qemu’s userspace
emulation provide for them?
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
