From owner-freebsd-arch Wed Jan 22 22:12:34 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADB3537B401; Wed, 22 Jan 2003 22:12:33 -0800 (PST) Received: from gnuppy.monkey.org (wsip68-15-8-100.sd.sd.cox.net [68.15.8.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C7FE43E4A; Wed, 22 Jan 2003 22:12:33 -0800 (PST) (envelope-from billh@gnuppy.monkey.org) Received: from billh by gnuppy.monkey.org with local (Exim 3.36 #1 (Debian)) id 18baap-0001vA-00; Wed, 22 Jan 2003 22:12:03 -0800 Date: Wed, 22 Jan 2003 22:12:03 -0800 To: Alfred Perlstein Cc: "M. Warner Losh" , bmilekic@unixdaemons.com, hsu@FreeBSD.ORG, arch@FreeBSD.ORG, "Bill Huey (Hui)" Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030123061203.GA7305@gnuppy.monkey.org> References: <0H94005IYWJT1Z@mta5.snfc21.pbi.net> <20030122162531.B77209@unixdaemons.com> <20030122.215336.55300145.imp@bsdimp.com> <20030123050542.GX42333@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030123050542.GX42333@elvis.mu.org> User-Agent: Mutt/1.5.3i From: Bill Huey (Hui) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jan 22, 2003 at 09:05:42PM -0800, Alfred Perlstein wrote: > Either locks are being held too long, or allocations are being done > in the wrong places. > > When we have proper priority inheritance and low memory callbacks > then we will not have to worry about latency. Simple priority inheritence doesn't prevent deadlocking. It's only one of many techiques to find a kind of localized solution inside a task synchronization search space. For something to be be more complete, you'd have to do a pretty exhaustive analysis of this space, determine which priority inversion protocol you want to use, etc... and then implement it. I'm not a dedicated hard core RT person, but I do know this bit is true and an investigation of the theory behind this analysis will support this. It's just a simple solution for a relatively simple synchronization system. You can't just create an arbitrarily complicated lock scenario in a kernel, apply a kind of simple priority inheritence anu hope that stuff works without strange anomalies. If possible, simplifying a system is probably the best solution, remove funky waits, try to hold as few resources as possible, etc... That's all I have to say. :) bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message