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
