[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090512.214427.193728136.davem@davemloft.net>
Date: Tue, 12 May 2009 21:44:27 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: mingo@...e.hu
Cc: a.p.zijlstra@...llo.nl, cfriesen@...tel.com, tglx@...utronix.de,
rostedt@...dmis.org, linuxppc-dev@...abs.org, paulus@...ba.org,
netdev@...r.kernel.org
Subject: Re: question about softirqs
From: Ingo Molnar <mingo@...e.hu>
Date: Tue, 12 May 2009 11:23:48 +0200
>> Wouldn't the even better solution be to get rid of softirqs
>> all-together?
>>
>> I see the recent work by Thomas to get threaded interrupts
>> upstream as a good first step towards that goal, once the RX
>> processing is moved to a thread (or multiple threads) one can
>> priorize them in the regular sys_sched_setscheduler() way and its
>> obvious that a FIFO task above the priority of the network tasks
>> will have network starvation issues.
>
> Yeah, that would be "nice". A single IRQ thread plus the process
> context(s) doing networking might perform well.
Nice for -rt goals, but not for latency.
So we're going to regress in this area again? I can't see how
that's so desirable, to be honest with you.
The fact that this discussion started about a task with a certain
priority not being able to make forward progress, even though it
was correct coded, just because softirqs are being processed in
a thread context, should be a big red flag that this is a buggered up
design.
I fully expected us to be, at this point, talking about putting the
pending softirq check back into the trap return path :-/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists