From owner-freebsd-arch  Sat Jan 25 15:50: 9 2003
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 34E9637B401; Sat, 25 Jan 2003 15:50:08 -0800 (PST)
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id C933E43F43; Sat, 25 Jan 2003 15:50:07 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (localhost [127.0.0.1])
	by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0PNo60i009490;
	Sat, 25 Jan 2003 15:50:06 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0PNo6xO009489;
	Sat, 25 Jan 2003 15:50:06 -0800 (PST)
Date: Sat, 25 Jan 2003 15:50:06 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200301252350.h0PNo6xO009489@apollo.backplane.com>
To: Jeff Roberson <jroberson@chesapeake.net>,
	Steve Kargl <sgk@troutmask.apl.washington.edu>,
	Robert Watson <rwatson@FreeBSD.ORG>,
	Gary Jennejohn <garyj@jennejohn.org>, <arch@FreeBSD.ORG>
Subject: Re: New scheduler (#2)
References: <20030125171217.D18109-100000@mail.chesapeake.net> <200301252320.h0PNKVoq090077@apollo.backplane.com>
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

    I found another problem.  In sched_exit() you are 'returning'
    part of the child's priority and interactivity to the parent, but
    you are not taking into account batch processes.

    A batch child which is exiting, such as the 'cc1' in a 'cc' or the 'cc'
    in a 'make' (you see where this is leading?  Consider a 'make buildworld')
    must penalize the parent so the next fork/exec'd child retains the batch
    priority.

    The 4bsd code does this.  The sched_smp code does not.  The sched_smp
    code simply adds to kg_slptime and this can *never* penalize the parent.
    The result is that the parent retains its near-zero cpu utilization
    (because all it is doing is fork/exec/wait).

    This could be the primary cause of the interactive/buildworld latency
    reports.

						-Matt


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message