Date: Tue, 07 Aug 2001 02:11:10 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Mike Smith <msmith@freebsd.org> Cc: 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: <3B6FB0AE.8D40EF5D@mindspring.com> References: <200108070739.f777dmi08218@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote: > > > 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 > > 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 > > the big giant lock and redirecting interrupts to "the CPU in > > the kernel" is better than that... > > Terry, this is *total* garbage. > > Just so you know, ok? What "this", exactly? That "virtual wire" mode is actually a bad idea for some applications -- specifically, high speed networking with multiple gigabit ethernet cards? That Microsoft demonstrated that wiring down interrupts to a particular CPU was a good idea, and kicked both Linux' and FreeBSD's butt in the test at ZD Labs? That taking interrupts on a single directed CPU is better than taking an IPI on all your CPUs, and then sorting out who's going to handle the interrupt? Can you name one SMP OS implementation that uses an "interrupt threads" approach that doesn't hit a scaling wall at 4 (or fewer) CPUs, due to heavier weight thread context switch overhead? Can you tell me how, in the context of having an interrupt thread doing scheduled processing, how you could avoid an interrupt overhead livelock, where the thread doesn't get opportunity to run because you're too busy taking interrupts to be able to get any work done? FWIW, I would be happy to cite sources to you, off the general list. -- Terry 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?3B6FB0AE.8D40EF5D>