Messages in this thread | | | Date | Thu, 22 Jul 2004 11:51:11 +0200 | From | Ingo Molnar <> | Subject | Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch |
| |
* 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |