From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 30 22:51:35 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3296A1065671 for ; Wed, 30 Apr 2008 22:51:35 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outh.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 114298FC14 for ; Wed, 30 Apr 2008 22:51:34 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 30 Apr 2008 21:09:18 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 1F6D32D6015; Wed, 30 Apr 2008 15:51:34 -0700 (PDT) Message-ID: <4818F7F8.6020602@elischer.org> Date: Wed, 30 Apr 2008 15:51:36 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Murty, Ravi" References: <4818E40F.9070004@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: maybe_preempt_in_ksegrp X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2008 22:51:35 -0000 Murty, Ravi wrote: > Julian, > > Apologies for sticking to 6.x, I checked and looks like this function > and several others are out in 7.x. It's just that we've been using 6.x > for a while and continue to look at it. :) > > > Coming back, I was thinking of the problem the other way around. The > thread gets put on the ksegrp runq, but we don't know if it gets put at > the head of the queue. All we know is we either find a slot or not. If > we do, great sched_add is called which will add it to a CPU runq and > check if it can preempt some thread on the target CPU. If we can't find > a slot, it checks if it can steal (preempt) some other thread (of the > same ksegrp) from a cpu. Let's consider the UP case to keep this simple. > One of the checks is the priority of the newly runnable thread and the > curthread on the CPU and the fact that they are part of the same KSEGRP. > If both pass, I think it should say "run me" since we just established > that I am higher priority than what's running on the CPU. > > Ravi > Quite possibly.. where were you when we needed more man-power on this :-) this was part of the attempt to make a 'fair' scheduler which would not gove a person 10,000 times the cpu just because he had 10000 threads :-) It was eventually removed as being too complicated, too resource intensive, and not solving a problem that people were seeing.