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

[Scott Wood]

On Thu, Jul 22, 2004 at 11:51:11AM +0200, Ingo Molnar wrote:
> * Scott Wood <scott@xxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/