From owner-freebsd-current Mon Nov 25 17: 6:36 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F32337B401; Mon, 25 Nov 2002 17:06:35 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92FEE43ED1; Mon, 25 Nov 2002 17:06:34 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id UAA28159; Mon, 25 Nov 2002 20:06:17 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id gAQ15kZ75838; Mon, 25 Nov 2002 20:05:46 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15842.51434.862239.412681@grasshopper.cs.duke.edu> Date: Mon, 25 Nov 2002 20:05:46 -0500 (EST) To: Bosko Milekic Cc: Julian Elischer , Robert Watson , Luigi Rizzo , current@freebsd.org Subject: Re: mbuf header bloat ? In-Reply-To: <20021125174315.C75673@unixdaemons.com> References: <15840.8629.324788.887872@grasshopper.cs.duke.edu> <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> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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