Messages in this thread | | | Date | Mon, 27 Sep 2004 08:03:03 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: [time] add support for CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |