From owner-freebsd-current@FreeBSD.ORG Mon Dec 6 09:18:52 2004 Return-Path: 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 2118516A4CE for ; Mon, 6 Dec 2004 09:18:52 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B34FE43D45 for ; Mon, 6 Dec 2004 09:18:51 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iB69GUft059079; Mon, 6 Dec 2004 04:16:30 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iB69GUSM059076; Mon, 6 Dec 2004 09:16:30 GMT (envelope-from robert@fledge.watson.org) Date: Mon, 6 Dec 2004 09:16:30 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Stephan Uphoff In-Reply-To: <1102304723.56978.113.camel@palm.tree.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Barney Wolff cc: "current@freebsd.org" Subject: Re: mbuf count negative X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2004 09:18:52 -0000 On Sun, 5 Dec 2004, Stephan Uphoff wrote: > I am wondering if critical sections are overkill for this application > since the interrupt blocking capability is not needed. > > Perhaps a mutex_lock_local, mutex_unlock_local that work on per CPU > mutexes and require the current thread to be pinned to a CPU would be > more appropriate. The functions would have the same functionality as > mutex_lock/mutex_unlock but without using atomic operations. The > "local" mutex would be a clone of the UP sleep mutex and the SMP sleep > mutex and the local mutex could even be used together in any order. > (With working priority inheritance) I think I will try this in my p4 > mutex branch in the next days. > > A "do not preempt" section (Interrupt enabled) would be another > possibility. Silby suggested a UP mutex implementation on SMP to use with pinned threads a month or two ago, and that would work just fine here; I was having similar thoughts also -- while the critical sections are brief, there's really no reason not to allow preemption there. However, the critical section optimizations that I was referring to from John basically do what you suggest second: they implement critical sections via a software "Don't preempt". I don't really mind what the mechanism is, as long as they neither invoke cli/sti or use atomic operations, and it should be possible to easily substitute in the UMA code once my patch is in place. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research