Re: [time] add support for CLOCK_THREAD_CPUTIME_ID andCLOCK_PROCESS_CPUTIME_ID

[Christoph Lameter]

On Fri, 24 Sep 2004, Ulrich Drepper wrote:

> This is pretty useless.  Why would you need kernel support for this, it
> just measures realtime.

Glibc cannot do that reliably on an SMP system with its HP_TIMING
technique. Even systems with "synchronized" CPU timers typically have an
offset between the timers of different CPUs.

> We have an implementation of the CPU time in glibc which can easily be
> changed to support clocks of this precision if there are no usable
> timestamp counters (which is what is currently used).

Sorry it cannot be easily changed as I have repeatedly experienced.
I have posted lots of patches to address that issue for SMP systems which
were all rejected and you got insulted by my attempt to discuss the
problem and insisted that it was "solved".

> And all this is not really what was really meant by "CPU time" in the
> POSIX spec.  We hijacked this symbol, maybe incorrectly so.  What is
> really meant is how much time a process/thread actually _uses_ the CPU
> (hence the name).  I.e., the information contained in struct rusage.
>
> For this I would love to get kernel support and we hopefully have soon a
> patch for this.

Yes this may be easily addressed in the kernel. clock_gettime belongs
completely into the kernel. Could we get glibc to no longer handle clocks
on its own? The glibc code has always been horribly broken on SMP systems
and I fear that lots of software now assumes that CLOCK_PROCESS_CPUTIME_ID
gets you the runtime of the current process. The patch would allow this
software to run reliably on an SMP system.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/