[kernel] Implement high priority bottom half interrupt handlers

[ghaerr]

This PR implements the concept of "high priority" bottom half (BH) interrupt handlers as a potential solution for certain device drivers which may need their bottom half handlers to execute as soon as possible after their top half interrupt completes. [EDIT: A solution was found where all BH handlers execute as high priority, thus the strike-outs below.]

Currently, "normal" BH handlers may be are no longer delayed. due to the design decision of running them only when no other kernel code was previously executing, which essentially allows almost any code to be called from the bottom handler (except schedule() and sleep_on/do_wait etc of course), and guarantees that any interrupted kernel code completes before BH execution.

The current method of selecting when bottom half handlers can run is quite conservative, and purposely doesn't introduce changed code paths for more complex scenarios. This was done to ensure that system stability remains very high. Speeding up the current delay for normal BH handlers can likely be is now accomplished. but must be done with the ability to also test during more complex application and driver involvement.

When the system is busy executing other processes, it was found in #2533 that bottom half delays of 20-80ms (2-8 timer ticks) were sometimes occurring, until the system was relatively idle. For the timer_bh bottom half, this isn't too big a deal, since jiffies are incremented in the top half. But for network packet transmit/receive, this could result in much decreased networking speed.

Without more experimentation, it is hard to tell exactly how quickly a bottom half handler for various device drivers must be called, and thus a higher-priority implementation was designed. to allow either to be used very easily. In irq.h, the following code is used to define the execution order of bottom half routines

/* BH handlers, run in increasing numeric order */
enum {
//  NETWORK_BH = 0,         /* high priority */
    TIMER_BH = 1,           /* lower priority */
    SERIAL_BH,
    MAX_SOFTIRQ
};

The enumerated routines will be run in increasing numeric order. A BHM_HIPRI mask is used to designate which of the lowest-numbered routines have high priority, and these will now be executed as soon as possible (when marked) after the top half interrupt exits, while the remaining routines may be delayed as usual.

The unused NETWORK_BH is number 0, which designates it to be the first routine to run, and its mask value (1 << 0) is set in BHM_HIPRI to designate it as a high priority handler. The TIMER_BH runs next (when marked, of course) and is normal priority. (To add yet another high priority handler designate it as number 1, and set BHM_HIPRI to 3. The remaining handlers would then be numbered from 2 upwards).

Currently, no NIC drivers use BH handlers, and the timer BH is the only handler that ever runs. For reasons of keeping extreme stability in the kernel, the mechanism of exactly how/when the bottom half handlers run has not been changed, and won't likely be until more experimentation can occur with converted device drivers. The overall overhead of implementing high priority handlers is only 3 instructions/interrupt, so this won't affect much. The now-default fast serial drivers don't take this code path at all, so will have no effect on serial input speed.

Discussion on strategies for writing top/bottom half NIC interrupt handlers is occurring in Mellvik/TLVC#212.

[ghaerr]

After more testing, it was realized that all active bottom half handlers need to be executed as soon as possible, which means on the interrupt stack as soon as any previously stacked top half PIC interrupts complete and the stack is unwound. This prevents any delays seen from the previous design in #2533.

Since all BH handlers now run immediately after the interrupt stack is unwound, the concept of "high priority" handlers is no longer required and is being removed. The initial post has been edited to strike out any details of that feature.

Code was added to protected BH handlers from being reentered and the system now seems to run quite well with no delays.