Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jan 2003 22:24:40 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        bright@mu.org
Cc:        bmilekic@unixdaemons.com, hsu@FreeBSD.ORG, arch@FreeBSD.ORG
Subject:   Re: Alfre's malloc changes: the next step
Message-ID:  <20030122.222440.14643762.imp@bsdimp.com>
In-Reply-To: <20030123050542.GX42333@elvis.mu.org>
References:  <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
In message: <20030123050542.GX42333@elvis.mu.org>
            Alfred Perlstein <bright@mu.org> writes:
: * 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.

What is the solution then?  Waiting?  Why not dropping the request?
I'm not necessarily encouraging M_NOWAIT in these cases.  I am telling
you that M_NOWAIT is absolutely required for some applications and you
are picking nits with the examples I give.

: Either locks are being held too long, or allocations are being done
: in the wrong places.

There's lots of code in the tree that's way wrong then.

: When we have proper priority inheritance and low memory callbacks
: then we will not have to worry about latency.

I'm interest in this.  Do you have references that explain what you'd
have in mind?

: M_NOWAIT should be the exception if even allowed at all.

You have to do it in interrupt context, where if you can't get memory
you drop the request to rate limit things coming in.  There are other
applications that need the "allocate and send or drop" semantics.  We
have several at work: If you don't do something on time, then you
shouldn't do it at all.  Not having the ability to get memory w/o
waiting can be a big problem.  Usually we prealloc, but we can't
always prealloc everything since packets can come in any time...

Warner

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?20030122.222440.14643762.imp>