Re: time.c CP0_COMPARE

Re: time.c CP0_COMPARE

[Ralf Baechle]

On Thu, Aug 29, 2002 at 10:39:36AM -0700, Jun Sun wrote:

> Ralf Baechle wrote:

> >  c0_compare = c0_count + mips_counter_frequency / HZ.
> > 
> > That's what the individual boards are currently doing themselves though that
> > should be done in generic code.
> > 
>
> Good idea.
> 
> The attached patch attempts to set the first interrupt. It should be benign 
> even if a system is not using CPU counter as timer interrupt.
> 
> I also updated the time.README, including a new section about implementation 
> on a SMP machine.

Applied though I think that this should also be done via start_secondary
that is we'll need some per_cpu_time_init analog to per_cpu_trap_init.
Also of course your change makes some cleanup possible as the initialization
no happens twice for a bunch of platforms.

  Ralf

Re: time.c CP0_COMPARE (and SMP IPI rambling)

[Jun Sun]

Ralf Baechle wrote:
> On Thu, Aug 29, 2002 at 10:39:36AM -0700, Jun Sun wrote:
> 
> 
>>Ralf Baechle wrote:
> 
> 
>>> c0_compare = c0_count + mips_counter_frequency / HZ.
>>>
>>>That's what the individual boards are currently doing themselves though that
>>>should be done in generic code.
>>>
>>
>>Good idea.
>>
>>The attached patch attempts to set the first interrupt. It should be benign 
>>even if a system is not using CPU counter as timer interrupt.
>>
>>I also updated the time.README, including a new section about implementation 
>>on a SMP machine.
> 
> 
> Applied though I think that this should also be done via start_secondary
> that is we'll need some per_cpu_time_init analog to per_cpu_trap_init.

Right now setting per-cpu timers is totally left to the board-dependent code. 
  Once we see more SMP boxes using this approach, I think it starts to be 
interesting to make some abstraction and support it in a systematic way, 
including support for using CPU counter as the per-cpu timer interrupt.

Using local_timer_emulation sounds like an attractive alternative to me, as we 
only need to set up one system-wide timer interrupt.  Conceptually it probably 
takes a little longer to run through timer_interrupt (due to IPI calls).  But 
if the hit on performance is very negligible, the simplicity might make it 
worthwile.

BTW, since I am here, I like to ramble on a little bit further.  Currently 
Linux supports two kinds of IPI (inter-processor interrupt) deliveries:

1) sender waiting for the interrupt handler to start
2) sender waiting for the interrupt handler to start and complete

I think we really should the third kind:

3) sender does not wait at all.  Just delivers the interrupt.

With this support, the emulated local timer approach would have no performance 
penalty at all.

Jun

Re: time.c CP0_COMPARE (and SMP IPI rambling)

[Maciej W. Rozycki]

On Tue, 3 Sep 2002, Jun Sun wrote:

> Right now setting per-cpu timers is totally left to the board-dependent code. 
>   Once we see more SMP boxes using this approach, I think it starts to be 
> interesting to make some abstraction and support it in a systematic way, 
> including support for using CPU counter as the per-cpu timer interrupt.
> 
> Using local_timer_emulation sounds like an attractive alternative to me, as we 
> only need to set up one system-wide timer interrupt.  Conceptually it probably 
> takes a little longer to run through timer_interrupt (due to IPI calls).  But 
> if the hit on performance is very negligible, the simplicity might make it 
> worthwile.

 Well, the i386 approach (with a grain of salt, of course, but it's about
the most mature, anyway) seems reasonable.  A per-CPU local timer for
scheduling (no need to stability or high precision) and an external timer
interrupt for timekeeping (this one precise) that's delivered to a single
CPU at a time.  I hope there are no MIPS SMP systems that lack an external
timer IRQ source. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +