Date: Mon, 6 Dec 2004 09:16:30 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Stephan Uphoff <ups@tree.com> Cc: "current@freebsd.org" <current@FreeBSD.org> Subject: Re: mbuf count negative Message-ID: <Pine.NEB.3.96L.1041206091306.48524D-100000@fledge.watson.org> In-Reply-To: <1102304723.56978.113.camel@palm.tree.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041206091306.48524D-100000>