From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 00:35:05 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 258FA37B401; Tue, 8 Jul 2003 00:35:05 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF35C43FBF; Tue, 8 Jul 2003 00:35:03 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.9/8.11.4) with ESMTP id h687Z1sL017963; Tue, 8 Jul 2003 10:35:02 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3F0A7425.9080300@he.iki.fi> Date: Tue, 08 Jul 2003 10:35:01 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030501 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: deischen@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: thread scheduling priority with libkse X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2003 07:35:05 -0000 Daniel Eischen wrote: >The current thread. As I said before, if there are idle KSEs, then >one is woken to run the newly runnable thread. > I'm seeing about 200 microsecond latency when scheduling the thread on the other KSE. Which translates to maximum of 2500 "spins" of the contested loop a second. Same code runs about 500000 spins a second when no locking is involved. This is on othervise idle Dual 2.4 Xeon. If the mutex performance sounds about right, I need to redesign my locking to go from one contested lock to many uncontested ones, which sounds a good idea anyway. >It waits until either you hit a blocking condition or the >quantum expires. The library is not (yet) smart enough >to switch out the current thread after the unlock if the >new owner has a higher priority. We could do that, but >if there are other KSEs that can run the new thread, then >they should get it. > > > But the library is smart enough to extend the quantum on a higher priority thread if SCHED_RR is in effect? I'm seeing multiples of 20ms being allocated with two runnable threads of priorities 15 and 20 competing for the CPU. Pete