From: Benjamin LaHaise <bcrl@redhat.com>
To: Ulrich Drepper <drepper@redhat.com>
Cc: Andi Kleen <ak@suse.de>, Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Better CLONE_SETTLS support for Hammer
Date: Thu, 6 Mar 2003 00:29:45 -0500 [thread overview]
Message-ID: <20030306002945.A31972@redhat.com> (raw)
In-Reply-To: <3E66C5F4.5000106@redhat.com>; from drepper@redhat.com on Wed, Mar 05, 2003 at 07:52:20PM -0800
On Wed, Mar 05, 2003 at 07:52:20PM -0800, Ulrich Drepper wrote:
> Benjamin LaHaise wrote:
>
> > Instead,
> > making x86-64 TLS support based off of the stack pointer, or even using
> > a fixed per-cpu segment register such that gs:0 holds the pointer to the
> > thread "current" would be better.
>
> Gee, here is somebody who knows about thread APIs and ABIs. You're
> really embarrassing yourself.
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>
next prev parent reply other threads:[~2003-03-06 5:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-05 18:55 Better CLONE_SETTLS support for Hammer Ulrich Drepper
2003-03-05 19:06 ` Andi Kleen
2003-03-05 19:25 ` Ulrich Drepper
2003-03-05 21:19 ` Andi Kleen
2003-03-05 19:32 ` Ulrich Drepper
2003-03-05 21:21 ` Andi Kleen
2003-03-05 23:04 ` Ulrich Drepper
2003-03-06 1:05 ` Andi Kleen
2003-03-06 3:53 ` Ulrich Drepper
2003-03-06 4:14 ` Ulrich Drepper
2003-03-06 10:27 ` Andi Kleen
2003-03-06 18:58 ` Ulrich Drepper
2003-03-06 19:09 ` Andi Kleen
2003-03-06 2:08 ` Benjamin LaHaise
2003-03-06 3:52 ` Ulrich Drepper
2003-03-06 5:29 ` Benjamin LaHaise [this message]
2003-03-06 5:47 ` Ulrich Drepper
2003-03-06 5:33 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030306002945.A31972@redhat.com \
--to=bcrl@redhat.com \
--cc=ak@suse.de \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).