From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 4 17:43:29 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73D3316A41B; Thu, 4 Oct 2007 17:43:29 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id B829C13C478; Thu, 4 Oct 2007 17:43:23 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l94HhKxA020047; Thu, 4 Oct 2007 13:43:20 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Thu, 04 Oct 2007 13:43:20 -0400 (EDT) Date: Thu, 4 Oct 2007 13:43:20 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Alfred Perlstein In-Reply-To: <20071004170353.GR31826@elvis.mu.org> Message-ID: References: <20071003015231.GJ31826@elvis.mu.org> <86zlyzqmgo.fsf@ds4.des.no> <20071004094821.GM31826@elvis.mu.org> <86ejgbqjvr.fsf@ds4.des.no> <20071004101902.GN31826@elvis.mu.org> <20071004170353.GR31826@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Dag-Erling Sm??rgrav , hackers@freebsd.org Subject: Re: Critical Sections for userland. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2007 17:43:29 -0000 On Thu, 4 Oct 2007, Alfred Perlstein wrote: > * Daniel Eischen [071004 06:05] wrote: >> >> His point about telling us what you're really doing, so we might >> off other ways to do it is valid. >> >> We don't know why you are using homegrown user-level spinlocks >> instead of pthread mutexes. Priority ceiling mutexes and running >> in SCHED_RR or SCHED_FIFO is really what tries to address this >> problem, at least from the vague desciption you give. If you >> have tried this and they don't work correctly, then one solution >> is to fix them ;-) > > First of all we're stuck on 6.x, how is threads on this platform? I don't _think_ there is anything prohibitive of MFC'ing any libthr bug fixes into 6.x. I would have thought that you would have tried libthr on 6.x and possibly offered up "libthr performance sucks for me, and here's why" :-) You should probably ask David Xu about priority ceiling mutexes work on 6.x. > Second off we are contending against other devices in the system > that do not run FreeBSD, How do we address that? If you're running in real-time, then you are suppose to have priority over anything else except for ithreads. How much interrupt load is on your system and is ithread processing really going to impact you? If everything is working correctly and your thread that holds a priority ceiling mutex gets swapped out for an ithread, that thread should run again after the ithread. It shouldn't get swapped out for a different thread that doesn't also have its priority elevated (due to holding a similar mutex). I don't know if anyone other than possibly David Xu have tested SCHED_RR or SCHED_FIFO and priority ceiling mutexes, so they may not work as they're suppose to. -- DE