[PATCH] configure: introduce --{enable, disable}-syscall-clock
Eric Anholt
eric at anholt.net
Fri Apr 2 14:13:56 PDT 2010
On Mon, 29 Mar 2010 14:59:35 -0400, Adam Jackson <ajax at 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100402/a43dcbbc/attachment.pgp>
More information about the xorg-devel
mailing list