Date: Sat, 24 Jul 2010 13:02:43 -0700 (PDT) From: Doug Barton <dougb@FreeBSD.org> To: Alexander Motin <mav@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r210444 - head/sys/x86/x86 Message-ID: <alpine.BSF.2.00.1007241302300.94574@qbhto.arg> In-Reply-To: <4C4B4231.80406@FreeBSD.org> References: <201007241049.o6OAnxvo001874@svn.freebsd.org> <alpine.BSF.2.00.1007241224380.94574@qbhto.arg> <4C4B4231.80406@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 24 Jul 2010, Alexander Motin wrote: > Doug Barton wrote: >> On Sat, 24 Jul 2010, Alexander Motin wrote: >>> Author: mav >>> Date: Sat Jul 24 10:49:59 2010 >>> New Revision: 210444 >>> URL: http://svn.freebsd.org/changeset/base/210444 >>> >>> Log: >>> Increment td->td_intr_nesting_level for LAPIC timer interrupts. Among >>> other >>> things it hints SCHED_ULE to run clock swi handlers on their native >>> CPUs, >>> avoiding many unneeded IPI_PREEMPT calls. >> >> Will this help SCHED_4BSD at all? I'm finding it to be slightly better >> for interactivity on a loaded system, but frankly at this point they >> both leave a lot to be desired. > > At least not directly. SCHED_4BSD doesn't use this variable. But I have > no idea if the problem exist there. Even on SCHED_ULE it happens only in > some cases, if swi thread was accidentally pushed out of it's CPU by > higher priority thread. 4BSD has different migration logic, so behavior > could be different there. Ok, thanks. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1007241302300.94574>