Date: Wed, 2 Apr 2008 14:17:19 -0400 From: John Baldwin <jhb@freebsd.org> To: Jeff Roberson <jeff@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/sys callout.h src/sys/kern kern_clock.c kern_intr.c kern_timeout.c Message-ID: <200804021417.20141.jhb@freebsd.org> In-Reply-To: <200804021120.m32BKUYX089976@repoman.freebsd.org> References: <200804021120.m32BKUYX089976@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 02 April 2008 07:20:30 am Jeff Roberson wrote: > jeff 2008-04-02 11:20:30 UTC > > FreeBSD src repository > > Modified files: > sys/sys callout.h > sys/kern kern_clock.c kern_intr.c kern_timeout.c > Log: > Implement per-cpu callout threads, wheels, and locks. > > - Move callout thread creation from kern_intr.c to kern_timeout.c > - Call callout_tick() on every processor via hardclock_cpu() rather than > inspecting callout internal details in kern_clock.c. > - Remove callout implementation details from callout.h > - Package up all of the global variables into a per-cpu callout > structure. - Start one thread per-cpu. Threads are not strictly bound. > They prefer to execute on the native cpu but may migrate temporarily if > interrupts are starving callout processing. > - Run all callouts by default in the thread for cpu0 to maintain current > ordering and concurrency guarantees. Many consumers may not properly > handle concurrent execution. > - The new callout_reset_on() api allows specifying a particular cpu to > execute the callout on. This may migrate a callout to a new cpu. > callout_reset() schedules on the last assigned cpu while > callout_reset_curcpu() schedules on the current cpu. > > Reviewed by: phk > Sponsored by: Nokia This still has the bug in kern_intr.c:swi_add() as per previous e-mail. Surprised gcc didn't warn about it. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200804021417.20141.jhb>