Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch

* Scott Wood &lt;scott(a)timesys.com&gt; wrote: ok, i understand what you are trying to do. I dont think it makes much sense to preserve the throttling property of the current immediate/ksoftirqd processing. It was really an ad-hoc way to keep softirqs from monopolizing the CPU. The simplest solution for softirq deferral is to push it all into ksoftirqd and then let users change the priority/policy of ksoftirqd. it might make sense to create separate threads for each softirq level that exists currently: HI_SOFTIRQ=0, TIMER_SOFTIRQ, NET_TX_SOFTIRQ, NET_RX_SOFTIRQ, SCSI_SOFTIRQ, TASKLET_SOFTIRQ but this doesnt solve the problem either, because the current softirq splitup is too opaque - there's no priority-based distinction between softirq processing. Doing full softirq scheduling by attaching the softirq work to the process context that generates it (or an anymous context for things that are not connected to any particular existing context) is way too much work and not completely possible anyway. Much of the irq work <-> context information is lost at higher levels. We merge IO requests and do other optimizations. To track who generated what would be quite some work. so since we cannot do it perfectly i'd go for the simplest approach for now: defer to a single ksoftirqd per CPU. Then if someone comes up with a good patch to attach all hardirq/softirq processing to a particular context we can implement precise scheduling of hardirq/softirq work, based on the priority/policy of the context that generated/receives the interrupt event. Ingo