Date: Sun, 21 Aug 2005 20:41:16 +0400 From: Dmitry Mityugov <dmitry.mityugov@gmail.com> To: Garrett Cooper <youshi10@u.washington.edu> Cc: freebsd-questions@freebsd.org Subject: Re: polling decreases throughput ~50% Message-ID: <b7052e1e0508210941653a47e3@mail.gmail.com> In-Reply-To: <430894AA.8060605@u.washington.edu> References: <20050821123959.56599.qmail@web33304.mail.mud.yahoo.com> <430894AA.8060605@u.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/21/05, Garrett Cooper <youshi10@u.washington.edu> wrote: ... > Heh. We just discussed polling vs interrupts in an embedded systems > class this past quarter. Interrupts are better for more intermittent use > and polling is better for more frequent use, as polling is actually a > deadloop of course-for checking a flag most of the time-with potentially > a lot of wasted clock cycles before a context switch is made and the > task that was being polled for is run. Also, considering that actual > computer hardware isn't going to be running 100% of the time (except for > the CPU running idle tasks and stuff), interrupts are by far the better > way to go in general. But yeah... too many interrupts are bad as well... > Anyhow, that was sidetracking a bit :). Probably a good solution to this problem is to switch to the polling mode when you get an interrupt (or a few interrupts in a row), and switch back to the interrupt mode when the line has been idle for a while. --=20 Dmitry Mityugov, St. Petersburg, Russia I ignore all messages with confidentiality statements "We live less by imagination than despite it" - Rockwell Kent, "N by E"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b7052e1e0508210941653a47e3>