From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 30 21:12:12 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 3A9F9106566B for ; Wed, 30 Apr 2008 21:12:12 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id 11DD78FC0C for ; Wed, 30 Apr 2008 21:12:12 +0000 (UTC) (envelope-from ravi.murty@intel.com) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 30 Apr 2008 14:10:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.25,730,1199692800"; d="scan'208,217";a="323174078" Received: from orsmsx334.amr.corp.intel.com (HELO orsmsx334.jf.intel.com) ([10.22.226.45]) by fmsmga002.fm.intel.com with ESMTP; 30 Apr 2008 14:10:24 -0700 Received: from orsmsx416.amr.corp.intel.com ([10.22.226.46]) by orsmsx334.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 14:12:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 14:11:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: maybe_preempt_in_ksegrp Thread-Index: AcirBsOzIIs6vT8nSGydqLJ1uKALdQ== From: "Murty, Ravi" To: X-OriginalArrivalTime: 30 Apr 2008 21:12:11.0407 (UTC) FILETIME=[DB1921F0:01C8AB06] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 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 21:12:12 -0000 Hello All, =20 Looking through the scheduler code (kern_switch.c) and two functions that stood out were the following: =20 1. maybe_preempt_in_ksegrp - this function basically checks if the thread being made runnable should preempt another thread that is part of the same ksegrp. This makes sense. What I am having difficulty wrapping my brain around is the fact that if all checks pass, the kernel call mi_switch(SW_INVOL, NULL). The second parameter is NULL. This means that it expects sched_choose to pick a thread from the ksegrp. I would have expected it to say "I am preempting curthread because I am in the same ksegrp but higher priority, therefore switch to me".. the second parameter would have been td? When I compare this with what happens in mybe_preempt, the second parameter to mi_switch is the target thread because we're preempting the curthread (any ksegrp) to run the new thread. This makes sense. 2. Why do we check the state of the kse and make sure it is KES_THREAD. I would imagine that when this function is called, the state is exactly KES_THREAD? What am I missing here? =20 Thanks Ravi Murty