Date: Wed, 09 Feb 2005 12:21:45 -0700 From: Scott Long <scottl@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: obrien@freebsd.org Subject: Re: 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 Message-ID: <420A62C9.80405@freebsd.org> In-Reply-To: <200502091353.10200.jhb@FreeBSD.org> References: <200502082025.j18KP72E069507@repoman.freebsd.org> <20050209041221.GA16675@dragon.nuxi.com> <200502091353.10200.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?420A62C9.80405>