* Bosko Milekic <[EMAIL PROTECTED]> [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 [[EMAIL PROTECTED]]
Ok, who wrote this damn function called '??'?
And why do my programs keep crashing in it?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
