Date: Wed, 18 Apr 2001 01:35:44 +0000 (GMT) From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> To: Bosko Milekic <bmilekic@technokratis.com> Cc: Matt Dillon <dillon@earth.backplane.com>, Greg Lehey <grog@lemis.com>, Alfred Perlstein <bright@wintelcom.net>, "Justin T. Gibbs" <gibbs@scsiguy.com>, Doug Barton <DougB@DougBarton.net>, "current @ freebsd . org" <current@FreeBSD.ORG> Subject: Re: Kernel preemption, yes or no? (was: Filesystem gets a huge performance boost) Message-ID: <Pine.LNX.4.20.0104180120390.14246-100000@www.everquick.net> In-Reply-To: <20010417212045.B14803@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Tue, 17 Apr 2001 21:20:45 -0400 > From: Bosko Milekic <bmilekic@technokratis.com> > > What happens if we get an interrupt, we're thinking about servicing > it, about to check whether we're already holding a mutex that may > potentially be used inside the mainline int routine, and another CPU > becomes idle? In this particular case, let's say that we decide that we > have to set ipending and iret immediately, because we're already holding > a potential lock when we got interrupted. Isn't the result that we have > a second CPU idling while we just set ipending? (I could be missing > something, really). (Thinking hard... this is fun stuff...) > Also, some mainline interrupt code may need to acquire a really large > number of locks, but only in some cases. Let's say we have to first > check if we have a free cached buffer sitting somewhere, and if not, > malloc() a new one. Well, the malloc() will eventually trigger a chain > of mutex lock operations, but only in the case where we lack the cached > buffer to allocate it. There is no practical way of telling up front > whether or not we'll have to malloc(), so I'm wondering how efficiently > we would be able to predict in cases such as these? In this case, why not have a memory allocator similar to Hoard? Let's say that I have a four-way system with 256 MB. First CPU gets first 64 MB, second gets the next 64 MB, and so on. Now we needn't lock before malloc(), because each CPU knows ahead of time what is "off limits". When one reaches a high water mark, it steals half the available space from the CPU with the least memory utilization. This _would_ require a lock, but should only happen in rare instances. I know that memory could become fragmented over time, but as long as we don't screw up caching (which shouldn't be a problem considering that pages are much larger than cache lines), who cares? Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --------------------------------------------------------------------------- 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?Pine.LNX.4.20.0104180120390.14246-100000>