Messages in this thread | | | Date | Sat, 25 Sep 2004 07:51:32 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: [time] add support for CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID |
| |
On Fri, 24 Sep 2004, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Christoph Lameter wrote: > > > Then please sign off on the following patch: > > Sorry, I fail to see the point. The CPUTIME stuff will either way be > entire implemented at userlevel. If we use TSC, we compute the > resolution from the CPU clock speed (no need to comment, I know it's not > reliable everywhere). If we fall back on realtime, we will simply in > glibc map
I thought I heard you asking for CPUTIME returning the actual cputime used in the last message. I have proposed falling back to realtime in the past but that was not acceptable.
> > clock_getres (CLOCK_PROCESS_CPUTIME_ID, &ts) > > to > > clock_getres (CLOCK_REALTIME, &ts) > > The kernel knows nothing about this clock.
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?
Any implementation of the CPUTIME clocks is always easier to do in the kernel with just a few lines.
> The comment changes are OK, of course. > > If there is more to change this is in glibc. So far I have not heard of > anybody wanting to use the clocks this way. This is why we do not have > the fallback to realtime implemented. If you say you need it I have no > problem adding appropriate patches.
Ok, I will dig out my old patch and repost it to glibc-alpha. - 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/
| |