From owner-cvs-all@FreeBSD.ORG Sun Feb 1 07:55:11 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A03A316A4F9; Sun, 1 Feb 2004 07:55:11 -0800 (PST) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 2C14C43D1F; Sun, 1 Feb 2004 07:55:09 -0800 (PST) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 1 Feb 2004 15:55:08 +0000 (GMT) To: Don Lewis In-Reply-To: Your message of "Sat, 31 Jan 2004 22:45:32 PST." <200402010645.i116jW7E096596@gw.catspoiler.org> Date: Sun, 01 Feb 2004 15:55:05 +0000 From: Ian Dowse Message-ID: <200402011555.aa86743@salmon.maths.tcd.ie> cc: cvs-src@FreeBSD.org cc: jeff@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: bde@zeta.org.au Subject: Re: cvs commit: src/sys/kern sched_4bsd.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 15:55:11 -0000 In message <200402010645.i116jW7E096596@gw.catspoiler.org>, Don Lewis writes: >Yup, I missed the change in 1.59. I did a binary search to find the >version in vm_meter.c and found a slightly older version before the >SSLEEP code had been removed. > FYI, the original change seems to date back to May 1990: REV:7.7 vm_meter.c 1990/05/02 19:07:25 mckusick do not count processes in load average sleeping over one second --- vm_meter.c 1989/05/29 13:09:36 7.6 +++ vm_meter.c 1990/05/02 19:07:25 7.7 @@ -405,9 +405,10 @@ switch (p->p_stat) { case SSLEEP: + if (p->p_pri <= PZERO && p->p_slptime == 0) + nrun++; + /* fall through */ case SSTOP: - if (p->p_pri <= PZERO && p->p_stat == SSLEEP) - nrun++; if (p->p_flag & SPAGE) total.t_pw++; else if (p->p_flag & SLOAD) { The bug here is that p->p_slptime has just been incremented in schedcpu() immediately before loadav() is called, so it will never be 0 here. Fixing this now is likely to trigger a lot of questions and complaints, so it is left as an excercise for the brave :-) Ian