Hi Piscium,
I have two Arch desktops.
Desktop #1: MSI motherboard, Nvidia graphics with proprietary driver, Xfce on top of openbox. Desktop #2: Dell, Intel graphics, Xfce on top of openbox.
If I run strace <GUI app> where <GUI app> could be for example Mousepad or Emacs, and move the mouse I get lots of stuff in the trace in both desktops. In desktop #1 however most of trace consists of calls to clock_gettime. This seems weird to me. In the excerpt below which shows both seconds and nano seconds, in the same second there are lots of messages. Why? As far as I know there is nothing wrong with the clock, and there is no special X configuration, so why does one desktop shows calls to clock_gettime and the other not? Any ideas?
clock_gettime(CLOCK_MONOTONIC, {tv_sec=36619, tv_nsec=338313354}) = 0 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}], 3, 0) = 0 (Timeout)
It's normal to call clock_gettime() just before poll() as part of the calculation for poll()'s last parameter which is the time-out in milliseconds. Running xclock(1), I see this as poll() gets called for the next event after the enter and leave window events arrive, with the timeout getting shorter as the time to update the clock draws near.
clock_gettime(CLOCK_MONOTONIC, {tv_sec=36619, tv_nsec=338370693}) = 0 ... clock_gettime(CLOCK_MONOTONIC, {tv_sec=36619, tv_nsec=339305864}) = 0 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}], 3, 0) = 0 (Timeout)
It looks like something is looping, calling clock_gettime(), until a millisecond has passed and then another zero-time-out poll() is called. I suggest using the simplest X client you can which shows the issue, e.g. xev(1). strace can be told to not trace its write(2) output with ‘-e \!write’, assuming the exclamation mark of shell history needs escaping. I found a couple of pages which may be of interest. The first shows others having similar issues with Nvidia's driver. https://forums.developer.nvidia.com/t/high-cpu-usage-on-xorg-when-the-extern... The second, if you read the two other emails in the thread, fixes the problem by changing the kernel's clock source which may differ between your two test machines? -- Cheers, Ralph.