: Mutex creation can be expensive as it seems like each interrupt
: needs to register what sort of mutex it's interested in, when a
: mutex is created the list must be scanned and each interrupt
: updated.
The list is based in the interrupt structure. The cost is, what,
four or five
* E.B. Dreger <[EMAIL PROTECTED]> [010417 18:48] wrote:
> > Date: Tue, 17 Apr 2001 18:28:40 -0700
> > From: Alfred Perlstein <[EMAIL PROTECTED]>
> >
> > 1) interrupts are again fan-in, meaning if you block an interrupt
> > class on one cpu you block them on all cpus
>
> When would this b
* E.B. Dreger <[EMAIL PROTECTED]> [010417 18:36] wrote:
>
> In this case, why not have a memory allocator similar to Hoard?
It doesn't work, but it's close:
http://people.freebsd.org/~alfred/memcache/
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Represent yourself, show up at
:
: You cannot be pre-empted by an interrupt if you are holding a spin
: mutex, AFAIK, even under present implementation.
Since spin mutexes are going to be held all over the place, this
type of restriction would seem to be detrimental. If you can do all
the checking up-front
* Matt Dillon <[EMAIL PROTECTED]> [010417 17:47] wrote:
...
>
> Interrupts by definition know precisely what they are going to do, so by
> definition they know precisely which mutexes (if any) they may need
> to get. This means that, in fact, it is possible to implement a check
>
On Tue, Apr 17, 2001 at 05:47:23PM -0700, Matt Dillon wrote:
> Proposed:
>
> mainline kernel {
> get_spin_mutex(&somemutex);
> .
> .
> masked interrupt occurs, interrupt structure contains array
> of mutexes the interrupt will need. Ch
* Greg Lehey <[EMAIL PROTECTED]> [010417 17:02] wrote:
> On Tuesday, 17 April 2001 at 1:19:57 -0700, Alfred Perlstein wrote:
> > * Matt Dillon <[EMAIL PROTECTED]> [010415 23:16] wrote:
> >>
> >> For example, all this work on a preemptive
> >> kernel is just insan
:*sigh* Couldn't you have changed the subject line when discussing
:something of this importance?
:
:Greg
Sorry. Now I am so much in a huff I'm thinking about how all this
could be implemented from scratch with the 4.x base. I know, I know,
good luck Matt...
For example, this
