[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8739ztrnrp.wl%peterc@chubb.wattle.id.au>
Date: Mon, 22 Mar 2010 15:19:54 +1100
From: Peter Chubb <peter.chubb@...ta.com.au>
To: David Miller <davem@...emloft.net>
Cc: <peter.chubb@...ta.com.au>, <netdev@...r.kernel.org>
Subject: Re: [PATCH] Improved network performance by balancing Rx against other work
>>>>> "David" == David Miller <davem@...emloft.net> writes:
David> From: Peter Chubb <peter.chubb@...ta.com.au> Date: Mon, 22 Mar
David> 2010 15:04:24 +1100
>>>>>>> "David" == David Miller <davem@...emloft.net> writes:
>>
David> From: Peter Chubb <peter.chubb@...ta.com.au> Date: Wed, 17 Mar
>> However, softIRQ processing is still not being preempted by a
>> real-time process that wakes up.
David> I thought softirqs ran as threads in the -rt kernel, why
David> doesn't preemption work properly for those threads?
I'm using the standard kernel here -- softIRQs run as threads
scheduled as SCHED_NORMAL, but because they're in the kernel, they're
not preemptible without an explicit preemption point, as far as I can
tell. So hardware interrupts will run, and the budget/work done
mechanism will ensure that other softIRQs and in-kernel real-time
threads run, but userspace doesn't seem to get a look in.
>> I had a look at the Broadcom tg3, but it looks too hard to modify;
David> It's one of the best drivers in the locking area.
It looked good from that aspect, but used too many features of NAPI
for me to modify quickly, and still have a simple and
easy-to-understand patch.
Anyway, I'm intending to try to reproduce the results with a different
driver, as I said.
Peter C
--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au ERTOS within National ICT Australia
--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au ERTOS within National ICT Australia
--
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