Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Feb 2005 13:53:10 -0500
From:      John Baldwin <jhb@FreeBSD.org>
To:        obrien@FreeBSD.org
Cc:        cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/i386/i386 apic_vector.s local_apic.c mp_machdep.c src/sys/i386/include apicvar.h smp.h src/sys/i386/isa clock.c
Message-ID:  <200502091353.10200.jhb@FreeBSD.org>
In-Reply-To: <20050209041221.GA16675@dragon.nuxi.com>
References:  <200502082025.j18KP72E069507@repoman.freebsd.org> <20050209041221.GA16675@dragon.nuxi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

Speaking of benchmarks, how about testing the patches I posted to amd64@?  
Specifically, how about benchmarking the atomic patch to change membars to 
use the fence instructions?

-- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200502091353.10200.jhb>