On Mon, 13 Jul 1998, C. Scott Ananian wrote:
>On Mon, 13 Jul 1998, Andrew Derrick Balsa wrote:
....
>> Just one microscopic knitpicking, if you allow me: since reading the TSC is
>> *much* faster than latching the 8253/82C54 CTC, it should come first.
>>
>> And a question:
>> What are and why did you do those changes in /kernel/time.c? (I mean, I
>> understood those in /arch/i386/kernel/time.c)
>
>I agree with Andre's assessment and questions. Since we're banging on
>*i386*-architecture time brokenness, we should be very careful to leave
>the other architectures' stuff alone.
On Mon, 13 Jul 1998, Philip Gladstone wrote:
>>The stuff in sys_stime I meant to remove! However, it just eliminates
>the guts of stime and uses settimeofday instead. This is a goodness (TM)
>as we now have one fewer place where the clock is set!
>
I agree with you on the intention, but as mentionned by Scott, I think it would
be better to wait until we have ironed out all the i386 code (which has to
handle all the i386 time brokenness), and then step on to other parts of the
kernel. Just a question of timing, if I may say ;-)
> Also, I'm very queasy about messing
>with the inherent time hard-limits which protect monotonicity.
Scott was very careful about some changes I wanted to do, and I think he is
right.
>
>I'd love to see the improvements in your patch merged with the
>improvements in Andre's 2.0.x and my 2.1.x patches.
Me too :-)
[continuing Philip's message:]
On Mon, 13 Jul 1998, Philip Gladstone wrote:
>Actually, I'm now getting concerned about interrupts happening
>between doing the LATCH and the RDTSC. [pause to try an experiment]
Well, if you would revert the order (as I suggested above), you would be less
concerned :-). The RDTSC executes in a few CPU clock cycles, say 10: +/- 70 ns
on my 166MHz 6x86MX. The latch means an I/O cycle, which has a much higher
latency.
>
>Yup -- adding a cli() / restore pair around the crucial code
>in pentium_timer_interrupt helps a lot.
>
>I attach a chunk of code that can be used to test any
>kernel time implementation. It is truly horrible code.
>The way it works is to construct a user space emulation of
>clock_gettime based on reading the TSC, and then comparing this
>with gettimeofday. This code can be compiled with 'cc -O2'.
>I'm not going to explain the output, except to say that if it
>says 'This is not good at all!', then there are problems with
>the kernel timing code. There are various things that can be
>tweaked.
Going to test it now. Scott, I guess that's one more to add to the LTTS (Linux
Time Test Suite) :-)
It may be a good idea to gather the data somewhere, too.
Cheers,
---------------------
Andrew D. Balsa
andrebalsa@altern.org
-
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.altern.org/andrebalsa/doc/lkml-faq.html