Date: Mon, 06 Aug 2001 23:27:56 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Zhihui Zhang <zzhang@cs.binghamton.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: Allocate a page at interrupt time Message-ID: <3B6F8A6C.B95966B7@mindspring.com> References: <Pine.SOL.4.21.0108031432070.28997-100000@opal> <200108051955.f75Jtk882156@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote: > Yes, that is precisely the reason. In -current this all changes, though, > since interrupts are now threads. *But*, that said, interrupts cannot > really afford to hold mutexes that might end up blocking them for > long periods of time so I would still recommend that interrupt code not > attempt to allocate pages out of PQ_CACHE. 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.). 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 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?3B6F8A6C.B95966B7>