Hi, On Thu, Aug 12, 2010 at 09:47:23AM +0800, ykzhao wrote: > 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?
It's used by anything which calls GetTimeInMillis(), which is often to timestamp events sent to clients. We don't really need anything hugely fine-grained; certainly nothing greater than 1ms granularity. I'd happily ack a patch which uses CLOCK_MONOTONIC_COARSE in preference to CLOCK_MONOTONIC, in preference to gettimeofday(). Cheers, Daniel
signature.asc
Description: Digital signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
