> Date: Tue, 17 Apr 2001 21:20:45 -0400
> From: Bosko Milekic <[EMAIL PROTECTED]>
> 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?



Brotsman & Dreger, Inc.
EverQuick Internet / EternalCommerce Division

Phone: (316) 794-8922


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to