[RFC] use CLOCK_MONOTONIC_COARSE posix timer instead of CLOCK_MONOTONIC when calling the function of clock_gettime in xserver/os/util.c

[ykzhao]

Hi, All

      I meet with an issue about posix timer in course of testing media
workload on one machine. On this machine the HPET clock source is
selected as TSC stops in course of entering the deep C-state. 

     The issue is that the function of read_hpet will be called more
than 20000 every second when playing video workload on one machine. And
the matter is that it will take about 1800 cycles to read the HPET
counter(About 1us latency). According to the collected info, Xorg is the
first contributor of read_hpet. And the further analysis shows that one
contributor of read_hept in Xorg is caused by calling the
CLOCK_MONOTONIC posix timer. 

     In 2009 a guy from IBM added a CLOCK_MONOTONIC_COARSE posix timer,
which will return the time at the last tick. Compared with the
CLOCK_REALTIME/MONOTONIC, it is much faster as it can avoid the access
to the hardware. In such case the application can make the trade-off
between proper speed/granularity.
http://marc.info/?l=linux-kernel&m=125073483507611&w=2

   From the xorg server code it seems that the main purpose of
CLOCK_MONOTONIC posix timer in Xorg is to check the client's
request periodically. Is is acceptable that we use CLOCK_MONONIC_COARSE
posix timer with less accuracy instead of CLOCK_MONOTONIC in Xserver?

-----

We tried one debug patch that uses the CLOCK_MONOTONIC_COARSE timer
instead of CLOCK_MONOTONIC in xserver/os/utils.c. 

when playing flash h.264 cif video workload, the cpu C0 usage is reduced
from 43% to 42% while the video quality is not affected.


Best regards
    Yakui