"The Linux Gazette...making Linux just a little more fun!"

Linux gazette article, July 1999

From Chris Mikkelson on Mon, 19 Jul 1999

In your "answer guy" column, you made the following off-the-cuff comment:

It would be sheer idiocy for Linux to adopt a straight polling strategy for it's networking interfaces. However, it might be possible to have a hybrid. If the interrupt frequency on a given device exceeds one threshold the kernel might then switch to polling on that device. When the polling shows that the activity on that device as dropped back below another threshold it might be able to switch back to interrupt-driven mode.

Well, this reminded me instantly of a research paper I had recently read, called "Eliminating Receive Livelock in an Interrupt-driven Kernel." It is available online at

http://www.research.digital.com/wrl/techreports/abstracts/95.8.html

The problem with interrupt-driven processing is that the high overhead (and priority) of servicing an interrupt can starve the machine under high load. That is, not only does latency increase, but throughput can drop to practically zero under high load (this will be particularly evident on a gigabit-range network, 100baseT maybe, 10baseT -- a 486 can keep up with that

The solution implemented for the paper was as follows -- when receiving a network interrupt, start a polling task and disable that interrupt. When the polling task doesn't find significant new traffic for some number of cycles, stop the polling task and re-enable interrupts.

The platform this was implemented on was BSD (but I don't know if it made it into *BSD), but it could just as easily be done on Linux. It is also a rather simple and elegant solution, and drastically improved the behavior of the system under high loads.

It sounds similar to what I suggested, except that it sounds like you routinely disable the interrupt and switch to polling mode whereas I'd suggested that you'd only do it based on certain thresholds of activity.

In any event, you'd be welcome to submit a patch to the Linux kernel team.

Look in the CREDITS file for a list of e-mail addresses of major kernel developers. It's recommended that patches be initially sent to one of them (other than Linus) so that they can review it and marshall it towards the main kernel. Sending things directly to Linus might work, or it might get lost in the flood. It's not recommended. Let the others on the team see it first.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 44 August 1999

HTML transformation by Heather Stern of Starshine Techinical Services, http://www.starshine.org/

			1	4	7	9
			11	12	14	17
18	19	20	21	24	25	26
28	29	30	31	32	33	34
35	36	37	38	39	40	41
42	43	44	45	46	47	48