From owner-freebsd-hackers@FreeBSD.ORG Thu May 8 23:02:08 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 B0DE91065675 for ; Thu, 8 May 2008 23:02:08 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id 865658FC16 for ; Thu, 8 May 2008 23:02:08 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 08 May 2008 16:02:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.27,456,1204531200"; d="scan'208";a="244124155" Received: from orsmsx335.amr.corp.intel.com (HELO orsmsx335.jf.intel.com) ([10.22.226.40]) by azsmga001.ch.intel.com with ESMTP; 08 May 2008 16:02:07 -0700 Received: from orsmsx416.amr.corp.intel.com ([10.22.226.46]) by orsmsx335.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 May 2008 16:01:56 -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: Thu, 8 May 2008 16:01:54 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SW_PREEMPT and cpu runq Thread-Index: AcixWr2ketz2s5fHQtWGSFUSi3EgKgAAqI4wAACDEvA= References: <48237E60.9040007@elischer.org> From: "Murty, Ravi" To: "Murty, Ravi" , "Julian Elischer" X-OriginalArrivalTime: 08 May 2008 23:01:56.0370 (UTC) FILETIME=[8358BF20:01C8B15F] Cc: freebsd-hackers@freebsd.org Subject: RE: SW_PREEMPT and cpu runq 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: Thu, 08 May 2008 23:02:08 -0000 Oh, I find this happens only in ULE -- during sched_switch(), it sets KEF_HOLD and then calls setrunqueue(). This ensures that the thread does not migrate on preemptions. Ravi -----Original Message----- From: Murty, Ravi=20 Sent: Thursday, May 08, 2008 3:48 PM To: 'Julian Elischer' Cc: freebsd-hackers@freebsd.org Subject: RE: SW_PREEMPT and cpu runq I guess two places. 1. maybe_preempt() - I've decided to preempt a thread on a cpu and the outgoing thread is held (SW_PREEMPT) on the same cpu. 2. timer expires and thread is out of its slice (ULE), in this case I remove the load and re-add it back to the same (current) cpu. Sorry Julian, yes this is 6.2 Thanks much, Ravi -----Original Message----- From: Julian Elischer [mailto:julian@elischer.org]=20 Sent: Thursday, May 08, 2008 3:28 PM To: Murty, Ravi Cc: freebsd-hackers@freebsd.org Subject: Re: SW_PREEMPT and cpu runq Murty, Ravi wrote: > Hi, >=20 > =20 >=20 > When a thread is being switched out and it is being preempted (e.g. time > quantum expires), why does sched_switch hold it on the current cpu? i.e. > why does the code see that it was preempted and put it back on the same > queue? >=20 > In other cases it looks to see if it can be migrated and the thread goes > back some place else. If a thread is being kicked out and there is a > perfectly idle CPU some where on the system, wouldn't it make sense to > migrate the thread? it shouldn't be held.. why do you think it is? (and is this in 6.x still?) >=20 > =20 >=20 > Thanks > Ravi >=20 > =20 >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"