If you're saying that drawing an analagy between the kernel's concept
of the current task pointer and thread APIs is invalid, I'm rather
surprised. Ulrich, comments like this are unnecessarily inflammatory
and don't lead to a productive discussion of the merits and failings
of specific points.
> > Make the users of threads suffer, not
> > every single application and syscall in the system.
>
> Whether you like it or not, people are using threads. TLS requires a
> thread register even in single-threaded applications. The mechanism I
> proposed would use segments if <4GB addresses can be allocated,
> otherwise fall back to prctl(ARCH_SET_FS). This is about as good as you
> can get it.
My position is that requiring a thread register for unthreaded applications
is unnecessary bloat. Since the thread register is yet another register
that must be saved and reloaded on context switch, while it provides no
improvements in performance or functionality for single threaded programs,
it is pure bloat. Every single change like this that slows down unthreads
apps goes directly onto the boot and startup time of your system and
various applications. Think about it!
> Remove anything and hammer is the only architecture without good thread
> support which undoubtedly makes you happy but almost nobody else.
I'm trying to help reach a point of consensus where you are failing to
see Andi's point: using the TLS segment everywhere slows everything down
a tiny bit. Don't do it for unthreaded programs. We're trying to avoid
pessimizations while we still can for a new architecture. I fail to see
why you are not listening to this. Yes, threaded apps exist, but their
existance does not preclude the slowing down of unthreaded apps.
-ben
-- Junk email? <a href="mailto:aart@kvack.org">aart@kvack.org</a> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/