From owner-freebsd-threads@FreeBSD.ORG Wed Jul 9 14:36:49 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 1257837B401; Wed, 9 Jul 2003 14:36:49 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6645843FA3; Wed, 9 Jul 2003 14:36:48 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc13) with ESMTP id <20030709213648015007amt0e>; Wed, 9 Jul 2003 21:36:48 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA33228; Wed, 9 Jul 2003 14:36:42 -0700 (PDT) Date: Wed, 9 Jul 2003 14:36:41 -0700 (PDT) From: Julian Elischer 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: deischen@freebsd.org 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: Wed, 09 Jul 2003 21:36:49 -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. > As I said in othe rmail.. try setting machdep.cpu_idle_hlt to 0 > 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 > > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" >