[Qemu-devel] env in TLS

[Qemu-devel] env in TLS

[Piotr Krysik]

Hi!

Fabrice, how about moving env variable to TLS?

This could improve performance (based on 
http://lists.gnu.org/archive/html/qemu-devel/2004-09/msg00294.html

about 10% could be gained -- need to verify). Also 
additional register would be available for op.c 
(anyone to implement register renaming?).

The main problem with this approach is portability. 
AFAIK GCC <= 3.2 doesn't recognize __thread keyword. 
For x86 we could fall-back to the LDT method from 
qemu-fast. How about other platforms? In the worst 
case we could use global variable and forget about 
multi-processor qemu-softmmu and multi-thread in 
qemu-user for some platforms in the future.


Comments?

Piotrek


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Qemu-devel] env in TLS

[Fabrice Bellard]

Using TLS seems a good idea. I hesitated to implement it because I was 
not sure that segment overrides were as fast as an indexed memory access 
on all x86 processors. I think that imposing a gcc version >= 3.2 is no 
longer an issue. We must be sure that the other platforms support the 
__thread keyword though.

Fabrice.

Piotr Krysik wrote:
> Hi!
> 
> Fabrice, how about moving env variable to TLS?
> 
> This could improve performance (based on 
> http://lists.gnu.org/archive/html/qemu-devel/2004-09/msg00294.html
> 
> about 10% could be gained -- need to verify). Also 
> additional register would be available for op.c 
> (anyone to implement register renaming?).
> 
> The main problem with this approach is portability. 
> AFAIK GCC <= 3.2 doesn't recognize __thread keyword. 
> For x86 we could fall-back to the LDT method from 
> qemu-fast. How about other platforms? In the worst 
> case we could use global variable and forget about 
> multi-processor qemu-softmmu and multi-thread in 
> qemu-user for some platforms in the future.
> 
> 
> Comments?
> 
> Piotrek
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 

Re: [Qemu-devel] env in TLS

[Lennert Buytenhek]

On Mon, Oct 11, 2004 at 11:41:37AM +0200, Fabrice Bellard wrote:

> Using TLS seems a good idea. I hesitated to implement it because I was 
> not sure that segment overrides were as fast as an indexed memory access 
> on all x86 processors. I think that imposing a gcc version >= 3.2 is no 
> longer an issue. We must be sure that the other platforms support the 
> __thread keyword though.

At least the ARM (xscale) doesn't, even on gcc 3.3.3.  There's also
no NPTL for ARM, probably for that reason.

[root@enp2611 tmp]# uname -a
Linux enp2611.wantstofly.org 2.6.9-rc3 #12 Sun Oct 10 20:29:24 MEST 2004 armv4b armv4b armv4b GNU/Linux
[root@enp2611 tmp]# gcc --version
gcc (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
[root@enp2611 tmp]# cat x.c
#include <stdio.h>
 
int __thread xyzzy;
 
int main()
{
	return 0;
}
[root@enp2611 tmp]# gcc -Wall -o x x.c
x.c:3: error: thread-local storage not supported for this target
[root@enp2611 tmp]#


--L

Re: [Qemu-devel] env in TLS

[Johannes Schindelin]

Hi,

On Mon, 11 Oct 2004, Lennert Buytenhek wrote:

> int __thread xyzzy;
>
> int main()
> {
> 	return 0;
> }
> [root@enp2611 tmp]# gcc -Wall -o x x.c
> x.c:3: error: thread-local storage not supported for this target
> [root@enp2611 tmp]#

How about detecting that in configure? This way, even older gcc's can be
supported (like HAVE_GCC3_OPTIONS)...

Ciao,
Dscho

Re: [Qemu-devel] env in TLS

[Lennert Buytenhek]

On Mon, Oct 11, 2004 at 02:18:58PM +0200, Johannes Schindelin wrote:

> > int __thread xyzzy;
> >
> > int main()
> > {
> > 	return 0;
> > }
> > [root@enp2611 tmp]# gcc -Wall -o x x.c
> > x.c:3: error: thread-local storage not supported for this target
> > [root@enp2611 tmp]#
> 
> How about detecting that in configure? This way, even older gcc's
> can be supported (like HAVE_GCC3_OPTIONS)...

Sure, but if you want to support all platforms, you still won't be
able to use __thread unconditionally which was the original intent as
I understood it.


--L

Re: [Qemu-devel] env in TLS

[Johannes Schindelin]

Hi,

On Mon, 11 Oct 2004, Lennert Buytenhek wrote:

> Sure, but if you want to support all platforms, you still won't be
> able to use __thread unconditionally which was the original intent as
> I understood it.

What I meant:

in configure:

-- snip --
# check tls variable support
cat > $TMPC <<EOF
int __thread dummy;
EOF

can_use_tls="no"
if $cc -c -o $TMPO $TMPC 2> /dev/null ; then
   can_use_tls="yes"
fi

[...]

if test "$can_use_tls" = "no" ; then
  echo "NO_TLS=yes" >> $config_mak
fi

-- snap --

in Makefile:

-- snip --
ifeq ($(NO_TLS),yes)
CFLAGS+= -D__thread=
endif
-- snap --

Ciao,
Dscho

Re: [Qemu-devel] env in TLS

[Lennert Buytenhek]

On Mon, Oct 11, 2004 at 04:59:05PM +0200, Johannes Schindelin wrote:

> Hi,

Hi,


> -- snip --
> ifeq ($(NO_TLS),yes)
> CFLAGS+= -D__thread=
> endif
> -- snap --

So if your compiler doesn't support __thread, all threads will effectively
be using the very same "thread-local" variables, is that what you were
intending?


--L

Re: [Qemu-devel] env in TLS

[Rafael Espíndola]

I have done some experiments in using TLS instead of LDT in the case
of  the code-copying optimization:

http://lists.gnu.org/archive/html/qemu-devel/2004-09/msg00206.html
http://lists.gnu.org/archive/html/qemu-devel/2004-09/msg00248.html

Hope that it is useful.

Rafael

On Mon, 11 Oct 2004 01:32:28 -0700 (PDT), Piotr Krysik
<piotrek_priv@yahoo.com> wrote:
> Hi!
> 
> Fabrice, how about moving env variable to TLS?
> 
> This could improve performance (based on
> http://lists.gnu.org/archive/html/qemu-devel/2004-09/msg00294.html
> 
> about 10% could be gained -- need to verify). Also
> additional register would be available for op.c
> (anyone to implement register renaming?).
> 
> The main problem with this approach is portability.
> AFAIK GCC <= 3.2 doesn't recognize __thread keyword.
> For x86 we could fall-back to the LDT method from
> qemu-fast. How about other platforms? In the worst
> case we could use global variable and forget about
> multi-processor qemu-softmmu and multi-thread in
> qemu-user for some platforms in the future.
> 
> Comments?
> 
> Piotrek
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] env in TLS

[Johannes Schindelin]

Hi,

On Mon, 11 Oct 2004, Lennert Buytenhek wrote:

> So if your compiler doesn't support __thread, all threads will effectively
> be using the very same "thread-local" variables, is that what you were
> intending?

Basically, yes. Of course, this only works if __thread is only used for
performance reasons, not for real thread local variables (which wouldn't
work on those architectures and older gcc's anyway). Maybe it would be
cleaner to use another name, which spells out what we are doing with it,
like ATTRIBUTE_USE_TLS_FOR_PERFORMANCE ;-)

Ciao,
Dscho

Re: [Qemu-devel] env in TLS

[André Braga]

On Mon, 11 Oct 2004 11:41:37 +0200, Fabrice Bellard <fabrice@bellard.org> wrote:
> Using TLS seems a good idea. I hesitated to implement it because I was
> not sure that segment overrides were as fast as an indexed memory access
> on all x86 processors. I think that imposing a gcc version >= 3.2 is no
> longer an issue. We must be sure that the other platforms support the
> __thread keyword though.
 
I urge you not to tie QEMU even deeper on a specific compiler. I know
the techniques used on the emulator make it indeed quite tied to gcc,
however if there's any hope to support other compilers (for example
Intel's on x86 and IBM's on Linux and Mac OS X), then we should at
least try to support a broad selection of gcc compilers, from 2.95.3
on. This would buy us at least some degree of compatibility between
gcc versions, which should ease the path of making QEMU compatible
with more optimized compilers or even compilers to platforms which
still don't sport a GCC version.


Cheers,
A.

--
"A year spent in artificial intelligence is enough to make one believe in God"
Alan J. Perlis