cvs commit: src/sys/i386/i386 apic_vector.s local_apic.cmp_machdep.c src/sys/i386/include apicvar.h smp.h src/sys/i386/isa clock.c

[Scott Long]

John Baldwin wrote:
> On Tuesday 08 February 2005 11:12 pm, David O'Brien wrote:
> 
>>On Tue, Feb 08, 2005 at 08:25:07PM +0000, John Baldwin wrote:
>>
>>>jhb         2005-02-08 20:25:07 UTC
>>>
>>>  FreeBSD src repository
>>>
>>>  Modified files:
>>>    sys/i386/i386        apic_vector.s local_apic.c mp_machdep.c
>>>    sys/i386/include     apicvar.h smp.h
>>>    sys/i386/isa         clock.c
>>>  Log:
>>>  Use the local APIC timer to drive the various kernel clocks on SMP
>>>machines rather than forwarding interrupts from the clock devices around
>>>using IPIs: - Add an IDT vector that pushes a clock frame and calls
>>>    lapic_handle_timer().
>>
>>What is the performance improvement of this?  What benchmark is used to
>>show a benefit?
> 
> 
> Getting rid of these two IPIs means that no IPI handlers now need to access 
> spinlocks and we will now be able to look at allowing IPIs to fire while 
> spinlocks are held thus reducing latency for TLB shootdowns, etc.  Also, 
> making the clock stuff a little less synchronized (more like Alpha FWIW) 
> should reduce contention on sched_lock since {hard,stat,prof}clock() all bang 
> on sched_lock (i.e. all the CPUs don't always run fooclock() at the same 
> exact time now).  Also, by removing the need for functioning clocks when 
> using the APIC, we don't really have to care as much if the RTC and ISA timer 
> interrupts really work anymore when using an APIC (though I keep the "real" 
> clocks on UP systems for now).
> 
> I did not do any formal benchmarks, however and I don't think anyone else who 
> tested this did either.  Of course, I also posted these patches several weeks 
> ago and hardly anyone bothered to test them then (same for the spinlock_* 
> patches as well).  I can go work on some buildworld loop benchmarks though as 
> I haven't integ'd this into my work trees yet so I still have a base to 
> compare against.
> 

I did some testing under an earlier version of this work and found no
appreciable change in things like I/O and network thoroughput.  What you
committed is actually more efficient, so there might indeed be a (small)
gain.

Scott