From owner-freebsd-arch Wed Jan 22 21: 5:47 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 5561037B401; Wed, 22 Jan 2003 21:05:46 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04B4543F18; Wed, 22 Jan 2003 21:05:46 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 80A59AE1C6; Wed, 22 Jan 2003 21:05:42 -0800 (PST) Date: Wed, 22 Jan 2003 21:05:42 -0800 From: Alfred Perlstein To: "M. Warner Losh" Cc: bmilekic@unixdaemons.com, hsu@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030123050542.GX42333@elvis.mu.org> References: <0H94005IYWJT1Z@mta5.snfc21.pbi.net> <20030122162531.B77209@unixdaemons.com> <20030122.215336.55300145.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030122.215336.55300145.imp@bsdimp.com> User-Agent: Mutt/1.4i 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 * M. Warner Losh [030122 20:55] wrote: > In message: <20030122162531.B77209@unixdaemons.com> > Bosko Milekic writes: > : Not one of you has said why you think that the wait behavior should > : not be the default behavior and why the dontwait behavior shouldn't be > : treated like an exception. > > We are saying, but you aren't listening. We are concerned about the > kernel programmer paying attention to the sleepability of the kernel > calls they are making. We are concerned that making wait default will > lead to a larger standard deviation in the cases where the thread has > to wait. We are concerned about the use of locks and allocating > memory with the locks held (juding from the could sleep messages we > have a lot of this code). We are conerned about the interface being > correct. Encouraging the user to use M_NOWAIT to get around all these problems is not a solution. 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. M_NOWAIT should be the exception if even allowed at all. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message