22 Jul
2004
22 Jul
'04
4:51 p.m.
On Thu, Jul 22, 2004 at 11:51:11AM +0200, Ingo Molnar wrote:
* Scott Wood <scott(a)timesys.com> wrote:
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.
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.
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