Date: Wed, 22 Jan 2003 22:48:28 -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: <20030123064828.GY42333@elvis.mu.org> In-Reply-To: <20030122.222440.14643762.imp@bsdimp.com> References: <20030122162531.B77209@unixdaemons.com> <20030122.215336.55300145.imp@bsdimp.com> <20030123050542.GX42333@elvis.mu.org> <20030122.222440.14643762.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* M. Warner Losh <imp@bsdimp.com> [030122 21:25] wrote: > In message: <20030123050542.GX42333@elvis.mu.org> > Alfred Perlstein <bright@mu.org> writes: > : 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. The only place where it really makes any sense is interrupts where pre-alloc is impossible, or code that runs in the low memory deadlock avoidance path. > : 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. Yup. > : 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? It would take some work, but the idea being that any lock we have in the kernel needs an "owner" slot so that if a high priority thread blocks on it we loan its prio to the thread that holds the lock. The low memory callback is like what we have with mbufs, such that subsystems can register a callback that will be called when the system is low on resources so that it can toss out data it might not need. > > : 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... Which is one of the few the exceptions. I know that we need M_NOWAIT, but it's should not be considered in the toolbox we use to lock down the kernel. :) -- -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?20030123064828.GY42333>