Thread (1 message) 1 message, 1 author, 2006-09-23

Re: [PATCH] bcm43xx: further fix for periodic work errors

From: Larry Finger <hidden>
Date: 2006-09-23 19:06:57

Michael Buesch wrote:
On Saturday 23 September 2006 06:08, Larry Finger wrote:
quoted
Recent changes in the setup for preemptible periodic work fixed most
of the problems with NETDEV watchdog timeouts; however, some variants
of the bcm43xx device still had the problem. These were fixed by setting
the parameter MAXIMUM_BADNESS to 0. By doing so, all the functionality
associated with calculating the 'badness' of the upcoming periodic work
is no longer needed; therefore it is removed.
Uhm, no. Wait. _Why_ does the watchdog trigger.
All periodic work in the fastpath (which you remove with this patch)
is supposed to execute in a few microseconds.
I don't think we want to fix this my removing the fastpath and always
taking the _expensive_ slowpath periodic work.

So why does the watchdog trigger for the fast periodic work?
We need to find out.
Removing the fastpath is just bad for overall latency.

The two fastpath periodic works are 15 and 30, if executed
standalone. If the 15 and/or 30 is execiuted alongside with
a 60sec work, it's all slowpath, of course.
I was thinking that the 15 second periodic work called mac suspend, which is the most expensive part 
of the slowpath, but I see that is an unlikely condition. I'm now testing to see if moving the 
netif_tx_disable/netif_wake_queue pair into all paths fixes the errors. Those calls should be 
relatively inexpensive.

Larry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help