LWN: Comments on "Per-vector software-interrupt masking"

Per-vector software-interrupt masking

chantecode — Mon, 18 Feb 2019 02:43:36 +0000

That wouldn't be easy to do. It could easily miss out some subtleties, callback mazes, things hidden behind macros. Careful reviews plus some help from runtime analysis with lockdep seem to me the most reliable approach. But you have a point: we may not be able to test all the code we need to convert. The coverage is huge.

Per-vector software-interrupt masking

marcH — Sun, 17 Feb 2019 17:24:02 +0000

Sounds cool but I suspect PJ was hoping for some kind of *static* analysis finding all instances without having to run the corresponding code.

Per-vector software-interrupt masking

viro — Sat, 16 Feb 2019 16:01:30 +0000

"Bottom half" is an old term, and it had nothing to do with high-priority vs. low-priority interrupts. Top half of (kernel/driver/networking/etc.) consists of the process-synchronous parts; bottom half is everything async.

Hardware interrupts certainly belong in the latter. So do software interrupts. If anything, top half is *easier* to interrupt or preempt; the opposite of high-priority hwints.

Linux originally had all bottom-half work done in hardware interrupt handlers. Mechanism for doing bottom-half stuff outside of those had been added circa 0.98, when the first networking patchset went in. Got labelled as "bh", without clear opposition to IRQ handlers... Eventually, they've got renamed^Wreplaced with somewhat less sucky analogue called softirq.

You'd probably have to ask Linus to find out what was the rationale for naming conventions, but I suspect that it was something along the lines of "mechanism for doing bottom-half stuff outside of hardware interrupts - those we already have a term for"...

Per-vector software-interrupt masking

unixbhaskar — Sat, 16 Feb 2019 03:36:45 +0000

Cool !! looks promising and useful.

Per-vector software-interrupt masking

chantecode — Sat, 16 Feb 2019 01:26:55 +0000

Little correction: hrtimer softirq have been reintroduced since
"hrtimer: Implement support for softirq based hrtimers" 5da70160462e80b0ab8a6960cdd0cdd476907523

We should remove the comment saying it's obsolete.

Per-vector software-interrupt masking

chantecode — Sat, 16 Feb 2019 00:14:28 +0000

Sure, just rename a spin_lock_bh(lock) to spin_lock(lock) and lockdep should complain about which vector it
has seen the lock used on.

Per-vector software-interrupt masking

pj — Fri, 15 Feb 2019 21:31:30 +0000

I feel like some kind of code analysis could determine what the mask _could_ or maybe _should_ be. But maybe I'm too optimistic.