From owner-freebsd-arch  Sat Jan 25 15:20:34 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 9CEB537B401; Sat, 25 Jan 2003 15:20:33 -0800 (PST)
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 3EEFB43F5F; Sat, 25 Jan 2003 15:20:33 -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 h0PNKV0i090078;
	Sat, 25 Jan 2003 15:20:31 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0PNKVoq090077;
	Sat, 25 Jan 2003 15:20:31 -0800 (PST)
Date: Sat, 25 Jan 2003 15:20:31 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200301252320.h0PNKVoq090077@apollo.backplane.com>
To: Jeff Roberson <jroberson@chesapeake.net>
Cc: Steve Kargl <sgk@troutmask.apl.washington.edu>,
	Robert Watson <rwatson@FreeBSD.ORG>,
	Gary Jennejohn <garyj@jennejohn.org>, <arch@FreeBSD.ORG>
Subject: Re: New scheduler
References:  <20030125171217.D18109-100000@mail.chesapeake.net>
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

    Jeff, while investigating your patch I found a couple of possible
    issues which I think are causing the time problems.

    The first problem is sched_choose() appears to be causing a lot
    of ping-ponging because the swap is made permanent.  i.e. it
    swaps cpu queues but then the new queue (belonging to another cpu)
    becomes the current queue.  For the current choose it doesn't matter,
    but for the NEXT time choose is called it does.

    The second issue has to do with the way kg_slptime is calculated.
    It just doesn't look right to me.  I think a better solution is
    to add an additional field, kg_runtime, and rather then trying to
    decrement kg_slptime you instead increment kg_runtime, then use
    the ratio kg_runtime / kg_slptime to calculate the interactivity
    of the process.  If either kg_runtime or kg_slptime exceed
    SCHED_SLP_MAX, simply scale both down (to deal with overflows).

						-Matt


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