From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 30 23:50:44 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 EEB70106566C for ; Wed, 30 Apr 2008 23:50:44 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by mx1.freebsd.org (Postfix) with ESMTP id B9ADB8FC1C for ; Wed, 30 Apr 2008 23:50:44 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 30 Apr 2008 16:50:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.25,731,1199692800"; d="scan'208";a="240293425" Received: from orsmsx335.amr.corp.intel.com (HELO orsmsx335.jf.intel.com) ([10.22.226.40]) by azsmga001.ch.intel.com with ESMTP; 30 Apr 2008 16:50:44 -0700 Received: from orsmsx416.amr.corp.intel.com ([10.22.226.46]) by orsmsx335.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 16:50:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Apr 2008 16:49:58 -0700 Message-ID: In-Reply-To: <4818F7F8.6020602@elischer.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: maybe_preempt_in_ksegrp Thread-Index: AcirFL6rkrlrOAzHTSCc6f9AZmY5fAAB+Mww References: <4818E40F.9070004@elischer.org> <4818F7F8.6020602@elischer.org> From: "Murty, Ravi" To: "Julian Elischer" X-OriginalArrivalTime: 30 Apr 2008 23:50:43.0070 (UTC) FILETIME=[007DB9E0:01C8AB1D] 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 23:50:45 -0000 Sorry I wish I was part of the development effort. I am just coming on board with FreeBSD work. I guess ksegrps were implemented for the purpose of PROCESS_SCOPE threads and like you said avoiding a process from hogging the CPU. If every thread in the system has it's own ksegrp (SYSTEM_SCOPE) I don't see this call (maybe_preempt_in_ksegrp) ever getting called :). Thanks ravi -----Original Message----- From: Julian Elischer [mailto:julian@elischer.org]=20 Sent: Wednesday, April 30, 2008 3:52 PM To: Murty, Ravi Cc: freebsd-hackers@freebsd.org Subject: Re: maybe_preempt_in_ksegrp Murty, Ravi wrote: > Julian, >=20 > 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. :) >=20 >=20 > 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. >=20 > Ravi >=20 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=20 intensive, and not solving a problem that people were seeing.