Date: Mon, 25 Nov 2002 20:05:46 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Julian Elischer <julian@elischer.org>, Robert Watson <rwatson@freebsd.org>, Luigi Rizzo <rizzo@icir.org>, current@freebsd.org Subject: Re: mbuf header bloat ? Message-ID: <15842.51434.862239.412681@grasshopper.cs.duke.edu> In-Reply-To: <20021125174315.C75673@unixdaemons.com> References: <15840.8629.324788.887872@grasshopper.cs.duke.edu> <Pine.BSF.4.21.0211232306410.28833-100000@InterJet.elischer.org> <15841.17237.826666.653505@grasshopper.cs.duke.edu> <20021125130005.A75177@unixdaemons.com> <15842.27547.385354.151541@grasshopper.cs.duke.edu> <20021125160122.A75673@unixdaemons.com> <15842.37927.919140.910293@grasshopper.cs.duke.edu> <20021125174315.C75673@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bosko Milekic writes: > > Well, first of all, I never call kmem_malloc() with any locks held so > this argument about grabbing Giant while other locks are held is not > applicable in my case. Well, not for the mbuf allocator itself, but for its consumers. > Given that you call the allocator with locks held, then you should > only be doing so with M_DONTWAIT as an M_TRYWAIT call may result in a > call to m_drain() which - if you are holding any locks - may lead to > lock order reversals. So given that you can only call the allocator > with M_DONTWAIT for device drivers or any other code paths holding > locks, then it would make sense to just make the M_DONTWAIT case never Exactly. I think we're now in violent agreement. But in order for this to work, we need your mbuf kproc to replenish the caches in case of allocation failures. I'm happy to wait until 5.1 for decent performance, as long as I know its coming. Hopefully we'll have time to bring some of the more popular drivers out from under Giant in time for 5.1. > call the VM routines as well. Either that, or make sure that a call > to kmem_malloc() with M_DONTWAIT can do its job without requiring > Giant (is this possible?) The VM gurus are now aware of the problem and are working on it, but its not currently possible. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15842.51434.862239.412681>