From owner-freebsd-current Tue Dec 17 13: 5:33 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 44A8D37B401 for ; Tue, 17 Dec 2002 13:05:32 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8274E43EDC for ; Tue, 17 Dec 2002 13:05:31 -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.12.6/8.12.6) with ESMTP id gBHL5Sro008633 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 17 Dec 2002 16:05:28 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id gBHL5Nn18557; Tue, 17 Dec 2002 16:05:23 -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: <15871.37267.31358.280147@grasshopper.cs.duke.edu> Date: Tue, 17 Dec 2002 16:05:23 -0500 (EST) To: Kyunghwan Kim Cc: current@FreeBSD.ORG Subject: Re: INTR_MPSAFE to network device drivers In-Reply-To: <20021217202402.GA57385@ada.snu.ac.kr> References: <20021217191841.GA57094@ada.snu.ac.kr> <15871.31635.962334.855790@grasshopper.cs.duke.edu> <20021217195300.GB57094@ada.snu.ac.kr> <20021217202402.GA57385@ada.snu.ac.kr> 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 Kyunghwan Kim writes: > On Wed, Dec 18, 2002 at 04:53:00AM +0900, Kyunghwan Kim wrote: > > On Tue, Dec 17, 2002 at 02:31:31PM -0500, Andrew Gallatin wrote: > > > > mbuf and bpf routines are all mp-safe, so it seems that > > > > it is safe to make network device drivers out of Giant lock. > > > > Or is there any unresolved related issues? > > > > > > Yes, the mbuf allocator must occasionally call kmem_malloc(), which > > > requires Giant. This means no net driver can be made INTR_MPSAFE, > > > or it will eventually panic when kmem_malloc is called. > > > > I found and read the thread that you and Alan had discussed about this > > problem just before. Then what about making updated version of mb_pop_cont() > > that accepts occasionally acquiring Giant? > > Oh, sorry. Conclusion of the thread was preallocation. > But it doesn't seem that preallocation is the correct way. Well, the "right" way is bringing kmem_malloc() out from under Giant. Preallocation would just be an interim measure until kmem_malloc() was mp-safe. The VM maintainers were only recently made aware of this issue. I have no idea what the scope of the changes to make kmem_malloc() mpsafe would be, so I have no idea when kmem_malloc() will become mpsafe. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message