Date: Tue, 29 Mar 2005 00:03:07 +0200 From: Anthony Atkielski <atkielski.anthony@wanadoo.fr> To: freebsd-questions@freebsd.org Subject: Re: hyper threading. Message-ID: <166745080.20050329000307@wanadoo.fr> In-Reply-To: <8C701F3D30DD9E0-418-84A@mblk-d49.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> <1873266905.20050328201452@wanadoo.fr> <8C701F3D30DD9E0-418-84A@mblk-d49.sysops.aol.com>
next in thread | previous in thread | raw e-mail | index | archive | help
em1897@aol.com writes: > Do you know how MAX_INTS and Device Polling > work? I know how device polling works. MAX_INTS is the sort of identifier that probably occurs in seven trillion lines of code in the world, so I have no idea what it means. > 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? I didn't say anything about an operating system. > First of all, with original 8250 "PC" serial > ports, polling wouldn't have worked because there > was no buffering. No buffering was necessary. Even the oldest devices held the most recent character latched in the register, and that's what I picked up. It wasn't necessary to buffer the characters, as I picked them up as soon as they came in ... even at 38,400 bps. > So there were no "chunks" to deal with. The chunks I had in mind had nothing to do with the incoming serial data. They were outstanding tasks divided into small blobs that could be handled between two polls of the serial port. Most of them involved things like writing data to the display, scrolling or clearing the display, and emptying and processing the keyboard buffer, not to mention transmitting outgoing data as required. > Which is why someone probably told you it was "impossible". They thought it was impossible because they had never thought of just polling the port. With interrupt-driven I/O, it _was_ impossible. But I just decided to stop using interrupts to eliminate that problem. > If your MB had a later design, such as a 16550, then you could poll > and gain some efficiency. I allowed for buffered input, as I recall, but the PCs I used it on didn't have that, and it would work without it. > HOWEVER, modern controllers have much buffering, and the ability to > moderate interrrupts. With polling you have a minimum constant > overhead, even with no traffic. That's right, but it's a low overhead, compared to the overhead of interrupt service. > 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. I'm sure that's appropriate in some cases. In my case, it wasn't necessary. > So if you have good hardware, polling has negative effects on > performance. It ads overhead for no additional benefit. Polling improves performance in the circumstances I've described. The extra overhead is irrelevant as long as the system is less than 100% busy. -- Anthony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?166745080.20050329000307>