You have lost me here. Are there different HZes or aren't there?
The difference you make here is an artificial one. As long as you don't
change
HZ there is no other one. So once again what is the difference?
If HZ is 1000 Hz it may be wise to restrict ordinary users from using timers
at that frequency
if it has adverse effect on the system.
>
>Going with separate HZ values provides some flexibility. The network
>tools and procps could go to 800 HZ while times() stays at 100 HZ.
I don't know the times() call, and at this moment I cannot check it myself
as I do not have access
to a Linux computer (I'm on holiday right now). Maybe you can explain to me
why times() should return
100 instead of a higher value?
>
>>> + KERN_LINUX_COUNTER_HZ=77 /* int: Frequency of free running
counter
>> */
>>>
>>> This is a CPU hardware counter? I never would have guessed.
>>> CPU_COUNTER_HZ and CPU_TSC_HZ are more descriptive.
>>
>> The philosophy is that most processors have some form of counter.
>> Not all of them are in the CPU and they are not always called TSC.
>> I wanted something generic.
>
>Since "TSC" stands for "Time Stamp Counter", I think it fits well
>enough even on non-Intel hardware. Any counter of interest for this
>purpose is going to be in the CPU, though it may count at a slower
>speed than the processor core is running.
>
>Certainly this isn't a kernel or Linux feature.
Nope, but it may not be a CPU feature on other platforms as well.
The rationale is that it is a non portable clock, Linux specific. Compare
with the
counter on SGI which is called CLOCK_SGI_COUNTER. The HZ related to that
clock would then be called <XXX>_COUNTER_HZ.
I really do not think that the name is very important. So if Linus has a
preference for
one or the other that's fine with me.
>
>> Point taken, are you sure that all platforms can do 64 bit calculations?
>> (or does the compiler support it?)
>
>One or the other will handle the problem -- see other mail.
I've given the matter some thought, and I have come to the conclusion that
clock ticks
would be the right unit. In user space the struct timespec is converted into
ticks/jiffies or
whatever name. The number of ticks can be expresses as a long, which is 32
bits or 64
depending on the platform. The number is always relative to the current
time.
All checks are done in user space, struct timespec is converted to ticks of
the clock itself.
Absolute time is converted to relative time in user space.
Very neat. I think I have arrived at the Right Thing. Thanks.
Expect a new patch in three weeks plus some days. (when I'm back from
holydays).
Robert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/