From owner-freebsd-arch Sat Jan 25 19: 5:29 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 2E5C737B401; Sat, 25 Jan 2003 19:05:28 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A1E243E4A; Sat, 25 Jan 2003 19:05:27 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0Q35IV91485; Sat, 25 Jan 2003 22:05:18 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 25 Jan 2003 22:05:18 -0500 (EST) From: Jeff Roberson To: Matthew Dillon Cc: Steve Kargl , Robert Watson , Gary Jennejohn , Subject: Re: New scheduler In-Reply-To: <200301252320.h0PNKVoq090077@apollo.backplane.com> Message-ID: <20030125220155.E18109-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 25 Jan 2003, Matthew Dillon wrote: > Jeff, while investigating your patch I found a couple of possible > issues which I think are causing the time problems. Thanks for the feedback. > > 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. Eh? There are two queues per cpu. sched_choose() does not effect the run queues of cpus other than the current one. I'm not sure I understand where you're going with this. > > 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 > Yeah, I had intended to do something similar to this to fix the slptime. This helps deal with a priority drift that is possible with the current design. I think I'll make this change soon. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message