From owner-svn-src-stable-7@FreeBSD.ORG Wed Sep 30 20:21:41 2009 Return-Path: Delivered-To: svn-src-stable-7@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B947106568D; Wed, 30 Sep 2009 20:21:41 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) Received: from seaxch09.isilon.com (seaxch09.isilon.com [74.85.160.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3D91B8FC0C; Wed, 30 Sep 2009 20:21:41 +0000 (UTC) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Sep 2009 13:09:40 -0700 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E03171462@seaxch09.desktop.isilon.com> In-Reply-To: <20090930195254.GK3130@deviant.kiev.zoral.com.ua> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: svn commit: r197652 - stable/7/sys/kern Thread-Index: AcpCB/F4hoEOPZEATdG5OhhIomenHQAACIUA References: <200909301940.n8UJep9X024249@svn.freebsd.org> <20090930195254.GK3130@deviant.kiev.zoral.com.ua> From: "Matthew Fleming" To: "Kostik Belousov" , "Zachary Loafman" Cc: svn-src-stable@freebsd.org, svn-src-stable-7@freebsd.org Subject: RE: svn commit: r197652 - stable/7/sys/kern X-BeenThere: svn-src-stable-7@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for only the 7-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 20:21:41 -0000 > > sched_ule in stable/7 has a bug (introduced in r180607) where a thread > > that is running often will appear to not be running much at all. > Why is this not a problem on HEAD ? I can't say definitively there's not a bug on HEAD of some kind, but when I ran a CPU hog and looked at the output of top(1), on HEAD the hog was listed as near 100%, and on stable/7 it was listed as 0% after a few seconds for the system to settle. Since the code looked at least somewhat different and the bug did not reproduce on HEAD, I assumed it was only a problem on stable/7. I had to run HEAD code in a virtual machine, perhaps this made a difference? >From a code inspection standpoint, I don't see anything obvious. On stable/7, the set of ts_ltick in tdq_runq_rem() appears to be the reason a cpu hog was not getting incremented by sched_tick(). On HEAD this set is moved to sched_choose(). Thanks, matthew