Re: [PATCH] configure: introduce --{enable, disable}-syscall-clock
On Mon, 05 Apr 2010 10:20:04 -0400, Adam Jackson a...@redhat.com wrote: On Fri, 2010-04-02 at 11:13 -1000, Eric Anholt wrote: On Mon, 29 Mar 2010 14:59:35 -0400, Adam Jackson a...@redhat.com wrote: Yeah, it's not really something I want Linux to default to using either. I mean, we're going to want input threads, so slicing off librt just because it pulls in libpthread is a bit temporary. And Mesa's GLX support pulls in pthreads already, so the class of device where this applies is pretty thin. At the moment, clock_gettime() is the only reason I can't get Mesa off of libpthread. Before a bunch of ugly hacking in libdrm, the overhead From pthreads presence was around 10% CPU time on CPU-bound apps on i965. These days it's down to a few percent. I'm not sure you're blaming the right piece of the world there. If you're referring to: commit 0d7ad7e43ca212b1e9f16cd18f36493cab455e61 Author: Eric Anholt e...@anholt.net Date: Tue Oct 20 14:19:38 2009 -0700 intel: Only call clock_gettime once per unreference_final. then I'm pretty sure the overhead there was calling clock_gettime at all. The implementation doesn't have any interaction with thread support. Compare runtimes from: http://people.freedesktop.org/~ajax/syscall/ Pretty sure you'll find them to be just about identical. It seems to me like the real problem is that clock_gettime() isn't in glibc without the pthreads cost. Perhaps someone could look into that instead of hacking around it in its consumers? The clock_gettime() implementation is in librt because that's where all the POSIX realtime stuff lives. Moving it into glibc wouldn't be especially difficult, though you'd need to get the symbol versioning right. No, I was talking about this problem: anh...@pollan:anholt/src/glsl2% ldd /usr/lib/librt.so linux-gate.so.1 = (0xe000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb7761000) libpthread.so.0 = /lib/i686/cmov/libpthread.so.0 (0xb7748000) /lib/ld-linux.so.2 (0xb78cd000) By linking to librt to get clock_gettime, we pull in real pthreads, and all the mutex lock/unlocks everywhere else in our code go from free to ow ow ow stop it already. So we've relaxed a bunch of the locking in libdrm_intel and left it up to the user where the user was doing locking anyway for its requirements, and we've cut down the number of calls made to the parts that still do locking. pgpsqlpMi4avd.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] configure: introduce --{enable, disable}-syscall-clock
On Fri, 2010-04-02 at 11:13 -1000, Eric Anholt wrote: On Mon, 29 Mar 2010 14:59:35 -0400, Adam Jackson a...@redhat.com wrote: Yeah, it's not really something I want Linux to default to using either. I mean, we're going to want input threads, so slicing off librt just because it pulls in libpthread is a bit temporary. And Mesa's GLX support pulls in pthreads already, so the class of device where this applies is pretty thin. At the moment, clock_gettime() is the only reason I can't get Mesa off of libpthread. Before a bunch of ugly hacking in libdrm, the overhead From pthreads presence was around 10% CPU time on CPU-bound apps on i965. These days it's down to a few percent. I'm not sure you're blaming the right piece of the world there. If you're referring to: commit 0d7ad7e43ca212b1e9f16cd18f36493cab455e61 Author: Eric Anholt e...@anholt.net Date: Tue Oct 20 14:19:38 2009 -0700 intel: Only call clock_gettime once per unreference_final. then I'm pretty sure the overhead there was calling clock_gettime at all. The implementation doesn't have any interaction with thread support. Compare runtimes from: http://people.freedesktop.org/~ajax/syscall/ Pretty sure you'll find them to be just about identical. It seems to me like the real problem is that clock_gettime() isn't in glibc without the pthreads cost. Perhaps someone could look into that instead of hacking around it in its consumers? The clock_gettime() implementation is in librt because that's where all the POSIX realtime stuff lives. Moving it into glibc wouldn't be especially difficult, though you'd need to get the symbol versioning right. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] configure: introduce --{enable, disable}-syscall-clock
On Mon, 29 Mar 2010 14:59:35 -0400, Adam Jackson a...@redhat.com wrote: On Mon, 2010-03-29 at 11:02 -0700, Alan Coopersmith wrote: Tiago Vignatti wrote: Some systems might not want to link against rt and pthread libraries simply to implement monotonic clock, inside GetTimeInMillis(). For those, use a direct syscall instead. This patch keeps the new syscall version disabled by default - therefore not changing the original behaviour of the xserver build. The main concern was regarding some eventual performance degradation when not going through optimized code in C library, or because syscall is varargs based. That's actually my secondary concern - my primary concern is that on most non-Linux systems, the system libraries are the public, stable, supported, documented interface, and syscall() is a private implementation detail to those, which applications are strongly discouraged from calling directly. Yeah, it's not really something I want Linux to default to using either. I mean, we're going to want input threads, so slicing off librt just because it pulls in libpthread is a bit temporary. And Mesa's GLX support pulls in pthreads already, so the class of device where this applies is pretty thin. At the moment, clock_gettime() is the only reason I can't get Mesa off of libpthread. Before a bunch of ugly hacking in libdrm, the overhead From pthreads presence was around 10% CPU time on CPU-bound apps on i965. These days it's down to a few percent. It seems to me like the real problem is that clock_gettime() isn't in glibc without the pthreads cost. Perhaps someone could look into that instead of hacking around it in its consumers? pgpUT4KDV0U0S.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] configure: introduce --{enable, disable}-syscall-clock
On Mon, 2010-03-29 at 11:02 -0700, Alan Coopersmith wrote:
Tiago Vignatti wrote:
Some systems might not want to link against rt and pthread libraries simply
to
implement monotonic clock, inside GetTimeInMillis(). For those, use a direct
syscall instead.
This patch keeps the new syscall version disabled by default - therefore not
changing the original behaviour of the xserver build.
The main concern was regarding some eventual performance degradation when
not
going through optimized code in C library, or because syscall is varargs
based.
That's actually my secondary concern - my primary concern is that on most
non-Linux systems, the system libraries are the public, stable, supported,
documented interface, and syscall() is a private implementation detail to
those, which applications are strongly discouraged from calling directly.
Yeah, it's not really something I want Linux to default to using either.
I mean, we're going to want input threads, so slicing off librt just
because it pulls in libpthread is a bit temporary. And Mesa's GLX
support pulls in pthreads already, so the class of device where this
applies is pretty thin.
atropine:~% size /lib/lib{rt,pthread}.so.?
textdata bss dec hex filename
27358 624 212 281946e22 /lib/librt.so.1
88930 8808352 98162 17f72 /lib/libpthread.so.0
14 dirty pages just isn't that much. I suspect even cursory examination
of heap usage would find worse offenses. It's fine as a
microöptimization, but that's about it.
- ajax
signature.asc
Description: This is a digitally signed message part
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] configure: introduce --{enable, disable}-syscall-clock
Tiago Vignatti wrote: Some systems might not want to link against rt and pthread libraries simply to implement monotonic clock, inside GetTimeInMillis(). For those, use a direct syscall instead. This patch keeps the new syscall version disabled by default - therefore not changing the original behaviour of the xserver build. The main concern was regarding some eventual performance degradation when not going through optimized code in C library, or because syscall is varargs based. That's actually my secondary concern - my primary concern is that on most non-Linux systems, the system libraries are the public, stable, supported, documented interface, and syscall() is a private implementation detail to those, which applications are strongly discouraged from calling directly. There's also the question of whether you know the right syscall arguments to use for every single kernel that Xorg runs on - though it appears SYS_clock_gettime is common to at least Linux Solaris, I haven't checked any of the BSD's, Cygwin, or MacOS X. (Perhaps wrapping a #ifdef SYS_clock_gettime around the #define after you've included syscall.h would provide a little more safety there.) I don't object to having it as a special case for embedded systems which really need to avoid the small linker overhead, but don't want to make Xorg less portable, stable and debuggable on general-purpose OS'es. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
