Messages in this thread | | | Date | Tue, 5 Oct 2004 11:38:28 -0700 | From | Roland McGrath <> | Subject | Re: [PATCH] CPU time clock support in clock_* syscalls |
| |
> Your approach means that only a part of the range may be used. > What happens if a pid of say 2^31-10 is used with your API?
That is certainly true. On a 32-bit machine, a PID value above 2^29-1 cannot be used, by definition. So there is no "what happens", it just can't. Userland will need to reject huge PIDs before trying to encode them. PID_MAX_LIMIT is 2^22, so no actually valid PID can be a problem in practice.
> Does this approach take into consideration that the TSC or cputimer may be > different on each CPU of a SMP system?
Yes. If you consider the methodology I described, you'll see that it does. The absolute sched_clock time is never relevant here, so it doesn't matter that it differs between CPUs. I take a sample when the thread gets scheduled, and another when it gets descheduled (and perhaps others on the timer interrupts in between). So all I ever use is the difference between two samples taken on the same CPU.
> I just reviewed the code and to my surprise the simple things like > > clock_gettime(CLOCK_PROCESS_CPUTIME_ID) and > clock_gettime(CLOCK_THREAD_CPUTIME_ID) are not supported.
You seem to be confused. A clockid_t for a CPU clock encodes a PID, which can be zero to indicate the current thread or current process.
> The thread specific time measurements have nothing to do with the posix > standard and may best be kept separate.
Nonsense. POSIX defines the notion of CPU clocks for these calls, and that is what I have implemented.
Of course glibc is in charge of what the meaning of the POSIX APIs is. That is true for every call.
Thanks, Roland - 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/
| |