From owner-svn-src-stable-7@FreeBSD.ORG Wed Sep 30 19:53:02 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 576AE1065693; Wed, 30 Sep 2009 19:53:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id DF88A8FC13; Wed, 30 Sep 2009 19:53:01 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n8UJqsv9038009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Sep 2009 22:52:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n8UJqsGQ039860; Wed, 30 Sep 2009 22:52:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n8UJqsU9039859; Wed, 30 Sep 2009 22:52:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 30 Sep 2009 22:52:54 +0300 From: Kostik Belousov To: Zachary Loafman Message-ID: <20090930195254.GK3130@deviant.kiev.zoral.com.ua> References: <200909301940.n8UJep9X024249@svn.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fLj60tP2PZ34xyqD" Content-Disposition: inline In-Reply-To: <200909301940.n8UJep9X024249@svn.freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@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 19:53:02 -0000 --fLj60tP2PZ34xyqD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 30, 2009 at 07:40:51PM +0000, Zachary Loafman wrote: > Author: zml > Date: Wed Sep 30 19:40:51 2009 > New Revision: 197652 > URL: http://svn.freebsd.org/changeset/base/197652 >=20 > Log: > 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 ? > =20 > sched_ule has a much less accurate mechanism for determining how much > various threads are running. Every tick, hardclock_cpu() calls > sched_tick(), and the currently running thread gets it's ts_ticks > incremented. Whenever an event of interest happens to a thread, the > ts_ticks value may be decayed; it's supposed to be a rough running > average of the last 10 seconds. So there's a ts_ltick which is the last > tick we looked at decaying ts_ticks. > =20 > The increment in sched_tick() was slightly buggy on SMP, because a > thread could get incremented on two different CPUs in the rare case > where it was swapped from one which had run sched_tick() this tick to > one which hadn't. The fix that was used relied on ts_ltick and only > incremented ts_ticks if ts_ltick was not from the current tick. > This is buggy, because any time the thread began running on a CPU in the > current tick, we would have set ts_ltick to ticks, so if it was still > running at sched_tick() we wouldn't increment. > =20 > A system with a single process that hogs the CPU and is otherwise idle, > therefore, would look like all threads were at 0%. The threads not > running are really at 0%, and the hog is not getting its ts_ticks > incremented since it went through some other runq stats that set > ts_ltick. On a 2-way SMP the thread used to get shuffled regularly > between CPUs (I think fallout from this bug), so it would appear a > little over 50% busy. > =20 > The fix is to use a separate variable to record when the last > sched_tick() increment happened. > =20 > Submitted by: Matthew Fleming (matthew.fleming at isilon.com) > Reviewed by: zml, dfr > Approved by: dfr (mentor) --fLj60tP2PZ34xyqD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrDtxUACgkQC3+MBN1Mb4hxLwCgkNdUEoc7cNwLLUFe4zy68Qe4 zFEAoOXuU7ZABaWvR/2PbqDjxsy0lRfR =MzlZ -----END PGP SIGNATURE----- --fLj60tP2PZ34xyqD--