On Thu, Jul 22, 2004 at 11:51:11AM +0200, Ingo Molnar wrote: > * Scott Wood <[EMAIL PROTECTED]> wrote: > > 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.
Ideally, yes. However, there isn't currently a scheduling policy that allows the softirq thread to run as a moderately high priority realtime thread for a short period of time, and drop it to a low priority non-realtime thread if it runs for longer than it "should". Running it as one high priority non-realtime task would work if all you want to run are non-realtime tasks and very high priority RT tasks (which are intended to have higher priority than softirqs). This is assuming that a high-priority non-RT task will always preempt a lower priority task except when it has depleted its timeslice; I'm not familiar enough with the current scheduler to know whether that is the case. > 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. Splitting it that way would be nice from the perspective of giving the user the ability to place more importance on certain types of softirqs, but it's not what I was trying to do with the high/low threads. > so since we cannot do it perfectly i'd go for the simplest approach for > now: defer to a single ksoftirqd per CPU. The dual-thread model is about as simple as the immediate/thread split that is currently there, IMHO, and while not perfect, it is an improvement over having to pick only one policy/priority given the current choices of policy. -Scott
