From owner-freebsd-current@FreeBSD.ORG Sun Jul 1 20:21:48 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F145A16A421 for ; Sun, 1 Jul 2007 20:21:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C2AA913C447 for ; Sun, 1 Jul 2007 20:21:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1EA12474E3; Sun, 1 Jul 2007 16:21:48 -0400 (EDT) Date: Sun, 1 Jul 2007 21:21:48 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Abdullah Ibn Hamad Al-Marri In-Reply-To: <499c70c0707010956qdb45580s16a50c8795dbbcea@mail.gmail.com> Message-ID: <20070701211819.O46634@fledge.watson.org> References: <20070630085038.GA1473@roadrunner.q.local> <499c70c0707010956qdb45580s16a50c8795dbbcea@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: SCHED_4BSD: More than 1 process running on UP machine? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2007 20:21:49 -0000 On Sun, 1 Jul 2007, Abdullah Ibn Hamad Al-Marri wrote: > On 6/30/07, Ulrich Spoerlein wrote: >> Hi all, >> >> I upgraded to -CURRENT and am running with SCHED_BSD on an UP machine >> (where ULE has no advantage over BSD, right?) >> >> PS: whats the new state 'ucond' all about? > > SCHED_ULE runs MySQL faster in my UP server vs SCHED_4BSD with FreeBSD 7.0 > > As for uncond maybe someone could tell us about it, but I thunk it has to do > with libthr. With libthr, when a thread blocks waiting on a userspace mutex or condition variable, that is exposed to the kernel via the umtx system calls. You can look in kern_umtx.c for details, but the short of it is that the "ucond" state has to do with waiting on a condition variable associated with a umtx, so reflect in-application synchronization between threads. With the m:n libpthread, waiting and synchronization between threads wasn't explicitly visible to the OS, so you basically just saw "kserel", which meant that there were no runnable threads. Robert N M Watson Computer Laboratory University of Cambridge