From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S269340AbUIYOvv (ORCPT ); Sat, 25 Sep 2004 10:51:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S269344AbUIYOvv (ORCPT ); Sat, 25 Sep 2004 10:51:51 -0400 Received: from omx2-ext.sgi.com ([192.48.171.19]:58524 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S269340AbUIYOvt (ORCPT ); Sat, 25 Sep 2004 10:51:49 -0400 Date: Sat, 25 Sep 2004 07:51:32 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Ulrich Drepper cc: linux-kernel@vger.kernel.org Subject: Re: [time] add support for CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID In-Reply-To: <41550B77.1070604@redhat.com> Message-ID: References: <4154F349.1090408@redhat.com> <41550B77.1070604@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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.