From owner-freebsd-threads@FreeBSD.ORG Tue Jul 8 06:18:30 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 1B11937B401 for ; Tue, 8 Jul 2003 06:18:30 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7714143FDF for ; Tue, 8 Jul 2003 06:18:29 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h68DISAI022178; Tue, 8 Jul 2003 09:18:28 -0400 (EDT) Date: Tue, 8 Jul 2003 09:18:28 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Petri Helenius In-Reply-To: <3F0A7425.9080300@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2003 13:18:30 -0000 On Tue, 8 Jul 2003, Petri Helenius wrote: > 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. That's the time it takes for the KSE to be woken up in the kernel and scheduled. > 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. A higher priority thread will always be run over a low priority thread, regardless of quantum. So yes, quantum is continually extended as long as the thread remains the highest priority thread and continues to be runnable. The library currently uses 20msec for the round-robin interval. -- Dan Eischen