Study, analyze and improve the interrupt handling infrastructure in FreeBSD.

In detail, i will first complete the (already started) study of the existing framework, in order to locate bottlenecks and other problems.

Then i will work on removing these problems, implement any necessary mechanism to improve interrupt handling, and study the interaction between interrupts and any strictly correlated subsystems (i.e. the interaction between interrupt threads, kernel preemption and the scheduler).

1. finish the profiling of current and past (4.x) FreeBSD interrupt framework (both UP and SMP): the data gathered in this phase will be used later for comparisons and regression tests;

1. study the interactions between interrupt threads and scheduler, in particular study the scheduling in presence of kernel preemption;

1. implements interrupt filtering, following the framework devised in Darwin (or any other model that proves to be worthwhile);

1. select one suitable driver to be used to compare different approaches, and modify it to support different interrupt handling architectures (fast interrupt, ithread, taskqueue and polling), analyzing its performance in different scenarios;

1. provide documented code examples for the various approaches;

1. summarize all the results in a paper to be published later in a BSDCon conference.

I spent the last months studying the FreeBSD interrupt handling code and profiling it. During my experiments i found 'expensive' sections of code in term of cpu usage (i.e. the cpu accounting) and unclear behaviors in term of latency (i.e. kernel preemption): some of them were fixed, while others are still present.

First i plan to finish my analysis of actual FreeBSD interrupt framework, then study in depth the latency problem found when kernel preemption is turned on.

When enough data are gathered, the next step will consist of implementing new so lutions to handle interrupt: i.e. in the past there were discussions and work to implement Darwin's interrupt filtering, so i could continue that work or i'll implement any other mechanism described in literature or employed by another system that proves to be useful.

With the new framework(s) in place, a driver will be selected and all the previous experiments will be rerun to demonstrate the improvements over the previous models.

In the end, the results of the work will be collected in a paper to be published later at a BSDCon conference.

05 Aug:

The Summer of Code is almost done, and i think it's time to give a status update about my project.

The development was divided in 4 steps:

1. convert all the FAST handlers to look like filters, and modify the MD code to behave accordingly. [DONE]

1. break NEWBUS api: add a new parameter of tipe driver_filter_t to bus_setup_intr(), and convert all the drivers accordingly. [DONE]

1. convert a driver to the new model: filter+ithread. [DONE]

1. benchmark the different interrupt models and write some docs. [TBD]

So far the infrastructure is ready to be tested, in fact all the old drivers run unchanged (ithead only handler), or where sligthly modified to work wit the new world order (FAST handlers are filter only handler now): both my laptop and my desktop run NIC filtered drivers together with all the other drivers without problems.

Obviously, to benefit from the new model, drivers must be modified and i'm still experimenting in this direction cause there're at least 2 different paths that can be followed to convert a driver(both with pros and cons), and i'm unsure which one is the best, so i'll keep converting drivers to gather as much experience as possible.

Misc:

• A new interrupt storm logic for filter only drivers (old FAST handlers) was added: this way, the OS won't livelock anymore in presence of stray interrupts on line where no handlers were registered.

• INTR_FAST/IH_FAST were retired

• aac, bfe, em and iwi were converted to the new filter+ithread model, ath (maybe?) will be the next one.

TODO:

• review EOIing/masking code and low level routines (*.s) for archs !i386

• make the stray-storm interrupt logic MI code

• collect the results in a paper