Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Aug 2001 02:19:54 -0500
From:      Alfred Perlstein <bright@mu.org>
To:        Bosko Milekic <bmilekic@technokratis.com>
Cc:        Terry Lambert <tlambert2@mindspring.com>, Matt Dillon <dillon@earth.backplane.com>, Zhihui Zhang <zzhang@cs.binghamton.edu>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Allocate a page at interrupt time
Message-ID:  <20010807021954.Q85642@elvis.mu.org>
In-Reply-To: <20010807031832.A46112@technokratis.com>; from bmilekic@technokratis.com on Tue, Aug 07, 2001 at 03:18:32AM -0400
References:  <Pine.SOL.4.21.0108031432070.28997-100000@opal> <200108051955.f75Jtk882156@earth.backplane.com> <3B6F8A6C.B95966B7@mindspring.com> <20010807031832.A46112@technokratis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Bosko Milekic <bmilekic@technokratis.com> [010807 02:16] wrote:
> 
> On Mon, Aug 06, 2001 at 11:27:56PM -0700, Terry Lambert wrote:
> > I keep wondering about the sagicity of running interrupts in
> > threads... it still seems like an incredibly bad idea to me.
> > 
> > I guess my major problem with this is that by running in
> > threads, it's made it nearly impossibly to avoid receiver
> > livelock situations, using any of the classical techniques
> > (e.g. Mogul's work, etc.).
> 
> 	References to published works?
>  
> > It also has the unfortunate property of locking us into virtual
> > wire mode, when in fact Microsoft demonstrated that wiring down
> > interrupts to particular CPUs was good practice, in terms of
> > assuring best performance.  Specifically, running in virtual
> 
> 	Can you point us at any concrete information that shows this?
> Specifically, without being Microsoft biased (as is most "data" published by
> Microsoft)? -- i.e. preferably third-party performance testing that attributes
> wiring down of interrupts to particular CPUs as _the_ performance advantage.
> 
> > wire mode means that all your CPUs get hit with the interrupt,
> > whereas running with the interrupt bound to a particular CPU
> > reduces the overall overhead.  Even what we have today, with
> 
> 	Obviously.
> 
> > the big giant lock and redirecting interrupts to "the CPU in
> > the kernel" is better than that...

I really don't see what part of the current design specifically
disallows one to both:

1) force interrupts to be taken on a particular cpu.
2) if that thread gets switched out, have it put on a per-cpu
   runqueue when it becomes runable preventing another cpu from
   snatching it up.

I've already implemented #2, #1 requires touching hardware
which isn't something I like doing. :)

-- 
-Alfred Perlstein [alfred@freebsd.org]
Ok, who wrote this damn function called '??'?
And why do my programs keep crashing in it?

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010807021954.Q85642>