From owner-cvs-src-old@FreeBSD.ORG Wed Sep 30 19:41:14 2009 Return-Path: Delivered-To: cvs-src-old@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E14B10656A8 for ; Wed, 30 Sep 2009 19:41:14 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 0DC2D8FC34 for ; Wed, 30 Sep 2009 19:41:14 +0000 (UTC) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.3/8.14.3) with ESMTP id n8UJfDqZ069575 for ; Wed, 30 Sep 2009 19:41:13 GMT (envelope-from zml@repoman.freebsd.org) Received: (from svn2cvs@localhost) by repoman.freebsd.org (8.14.3/8.14.3/Submit) id n8UJfDS5069574 for cvs-src-old@freebsd.org; Wed, 30 Sep 2009 19:41:13 GMT (envelope-from zml@repoman.freebsd.org) Message-Id: <200909301941.n8UJfDS5069574@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: svn2cvs set sender to zml@repoman.freebsd.org using -f From: Zachary Loafman Date: Wed, 30 Sep 2009 19:40:51 +0000 (UTC) To: cvs-src-old@freebsd.org X-FreeBSD-CVS-Branch: RELENG_7 Subject: cvs commit: src/sys/kern sched_ule.c X-BeenThere: cvs-src-old@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 19:41:14 -0000 zml 2009-09-30 19:40:51 UTC FreeBSD src repository Modified files: (Branch: RELENG_7) sys/kern sched_ule.c Log: SVN rev 197652 on 2009-09-30 19:40:51Z by zml 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. 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. 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. 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. The fix is to use a separate variable to record when the last sched_tick() increment happened. Submitted by: Matthew Fleming (matthew.fleming at isilon.com) Reviewed by: zml, dfr Approved by: dfr (mentor) Revision Changes Path 1.214.2.10 +4 -1 src/sys/kern/sched_ule.c