Date: Mon, 28 Mar 2005 16:25:39 -0500 From: em1897@aol.com To: freebsd-questions@freebsd.org Subject: Re: hyper threading. Message-ID: <8C701F3D30DD9E0-418-84A@mblk-d49.sysops.aol.com> In-Reply-To: <1873266905.20050328201452@wanadoo.fr> References: 6667 <20050328142522.40982.qmail@web90210.mail.scd.yahoo.com> <1802825135.20050328164920@wanadoo.fr> <8C701C5A7BE6FEE-4B8-3F7A1@mblk-d50.sysops.aol.com> <1873266905.20050328201452@wanadoo.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
Do you know how MAX_INTS and Device Polling work? I can tell that you don't so why are you blabbering about how you kludged an ancient operating system to work-around poorly designed hardware? First of all, with original 8250 "PC" serial ports, polling wouldn't have worked because there was no buffering. So there were no "chunks" to deal with. Which is why someone probably told you it was "impossible". If your MB had a later design, such as a 16550, then you could poll and gain some efficiency. HOWEVER, modern controllers have much buffering, and the ability to moderate interrrupts. With polling you have a minimum constant overhead, even with no traffic. Using interrupt moderation, you get the best of both worlds, because the contollers will only interrupt at a pre-set "safe" interval, and there is no additional overhead. And when there is no traffic there are no interrupts. So if you have good hardware, polling has negative effects on performance. It ads overhead for no additional benefit. -----Original Message----- From: Anthony Atkielski <atkielski.anthony@wanadoo.fr> To: freebsd-questions@freebsd.org Sent: Mon, 28 Mar 2005 20:14:52 +0200 Subject: Re: hyper threading. 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 _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8C701F3D30DD9E0-418-84A>