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

[Ingo Molnar <mingo@elte.hu>]

* Scott Wood <scott@timesys.com> wrote:

> > what high/low semantics do you mean, other than the ordering of softirq
> > sources? (which is currently implemented via the __do_softirq() loop
> > first looking at the highest prio softirq.) So splitting up ksoftirqd
> > into two pieces seems like a separate issue.
> 
> I meant the current split between immediate-context softirqs (which
> are repesented in the patch by the high-priority ksoftirqd) and the
> low-priority thread which is used to avoid starvation while allowing
> softirqs to continue running if the system's otherwise more or less
> idle.

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