Re: [time] add support for CLOCK_THREAD_CPUTIME_ID andCLOCK_PROCESS_CPUTIME_ID

[Christoph Lameter]

On Sat, 25 Sep 2004, Ulrich Drepper wrote:

> > Yes and glibc will have to get through contortions to
> > simulate a clock that returns the actual cpu time used. Why not cleanly
> > do the clock_gettime syscall without doing any redirection of clocks?
>
> First of all, unnecessary kernel code where it is not needed.  And
> second, because with the definition of the CPUTIME clock in use for many
> years now not all variants can be handled in the kernel.  We use this
> clock to provide access to the TSC functionality.  This is nothing the
> kernel does.

The kernel can do the same now in a much more reliable way since it can
produce time with nanosecond accuracy.

> > Any implementation of the CPUTIME clocks is always easier to do in the
> > kernel with just a few lines.
>
> No, you don't know the glibc side.

Yes, I do know that in detail. I have proposed numerous patches for this
issue to glibc-alpha.

> > Ok, I will dig out my old patch and repost it to glibc-alpha.
>
> I haven't gotten an answer to the question "is there really any value in
> this kind of clock?".

My old patches implement what you suggested: fallback to CLOCK_REALTIME in
glibc if the cputimer is not reliable.

I do not really understand your question. The CLOCK_PROCESS_CPUTIME_ID is
a clock mandated by the POSIX standard and it should work reliably. There
is no question that this clock must be provided.

I do not care how it is done as long as it always works reliably. It is IMHO
the best solution to put that into the kernel since glibc does not really
have all the information available to provide this clock (f.e. the
information obtained via TSC is not adjusted properly since the kernel
time adjustments will not be applied to it) but I will respect your
preferred way to solving this issue.
-
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/