Date: Mon, 28 Mar 2005 20:14:52 +0200 From: Anthony Atkielski <atkielski.anthony@wanadoo.fr> To: freebsd-questions@freebsd.org Subject: Re: hyper threading. Message-ID: <1873266905.20050328201452@wanadoo.fr> In-Reply-To: <8C701C5A7BE6FEE-4B8-3F7A1@mblk-d50.sysops.aol.com> References: 6667 <20050328142522.40982.qmail@web90210.mail.scd.yahoo.com> <1802825135.20050328164920@wanadoo.fr> <8C701C5A7BE6FEE-4B8-3F7A1@mblk-d50.sysops.aol.com>
next in thread | previous in thread | raw e-mail | index | archive | help
em1897@aol.com writes: > Things have changed a bit since then, so I doubt that > "proof" has any relevance. The principles haven't changed at all. Servicing interrupts is an extremely high-overhead activity. There's a minimum amount of time it takes, no matter how short the interrupt routine. There comes a point when just the inherent cost of the context switch is responsible for most of the overall cost of the interrupt service, and with a large number of interrupts, the processor(s) can spend a great deal of time just switching contexts. Polling eliminates this overhead by simply checking for I/O to service when it is convenient for the OS. As long as polls occur frequently enough not to miss any pending I/O, it's faster than interrupt-driven I/O. The total number of instructions executed is often greater, because the OS tends to spin on its polling tasks, but the absolute time required to respond to a given I/O event can be much shorter. In my case, I divided all the work of the comm program into small bits that could be done in tiny chunks. Each time a chunk was completed, I polled the serial port. Since chunks never exceeded a certain size, I always managed to poll the port in less time than it took to receive a character, even at 38,400 bps. The system was busier than it would be with interrupts driving it, but it responded more quickly to incoming traffic, and there were no transfer timeouts, whereas with interrupts, the system was less busy, but it timed out very consistently at high communications rates. By using more processor but evening out the use of processor so that it was more consistently distributed, very high communication rates could be handled by the program. All of this remains permanently applicable today, and it is why some high-speed applications poll instead of waiting for interrupts. -- Anthony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1873266905.20050328201452>