Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jan 2003 21:05:42 -0800
From:      Alfred Perlstein <bright@mu.org>
To:        "M. Warner Losh" <imp@bsdimp.com>
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>
In-Reply-To: <20030122.215336.55300145.imp@bsdimp.com>
References:  <dillon@apollo.backplane.com> <0H94005IYWJT1Z@mta5.snfc21.pbi.net> <20030122162531.B77209@unixdaemons.com> <20030122.215336.55300145.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* M. Warner Losh <imp@bsdimp.com> [030122 20:55] wrote:
> In message: <20030122162531.B77209@unixdaemons.com>
>             Bosko Milekic <bmilekic@unixdaemons.com> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030123050542.GX42333>