Date: Wed, 22 Jan 2003 22:12:03 -0800 From: Bill Huey (Hui) <billh@gnuppy.monkey.org> To: Alfred Perlstein <bright@mu.org> Cc: "M. Warner Losh" <imp@bsdimp.com>, bmilekic@unixdaemons.com, hsu@FreeBSD.ORG, arch@FreeBSD.ORG, "Bill Huey (Hui)" <billh@gnuppy.monkey.org> Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030123061203.GA7305@gnuppy.monkey.org> In-Reply-To: <20030123050542.GX42333@elvis.mu.org> References: <dillon@apollo.backplane.com> <0H94005IYWJT1Z@mta5.snfc21.pbi.net> <20030122162531.B77209@unixdaemons.com> <20030122.215336.55300145.imp@bsdimp.com> <20030123050542.GX42333@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030123061203.GA7305>