9d02daf754
We discovered that PPPoATM has an excessively deep transmit queue. A queue the size of the default socket send buffer (wmem_default) is maintained between the PPP generic core and the ATM device. Fix it to queue a maximum of *two* packets. The one the ATM device is currently working on, and one more for the ATM driver to process immediately in its TX done interrupt handler. The PPP core is designed to feed packets to the channel with minimal latency, so that really ought to be enough to keep the ATM device busy. While we're at it, fix the fact that we were triggering the wakeup tasklet on *every* pppoatm_pop() call. The comment saying "this is inefficient, but doing it right is too hard" turns out to be overly pessimistic... I think :) On machines like the Traverse Geos, with a slow Geode CPU and two high-speed ADSL2+ interfaces, there were reports of extremely high CPU usage which could partly be attributed to the extra wakeups. (The wakeup handling could actually be made a whole lot easier if we stop checking sk->sk_sndbuf altogether. Given that we now only queue *two* packets ever, one wonders what the point is. As it is, you could already deadlock the thing by setting the sk_sndbuf to a value lower than the MTU of the device, and it'd just block for ever.) Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|---|---|---|
| .. | ||
| addr.c | ||
| addr.h | ||
| atm_misc.c | ||
| atm_sysfs.c | ||
| br2684.c | ||
| clip.c | ||
| common.c | ||
| common.h | ||
| ioctl.c | ||
| Kconfig | ||
| lec.c | ||
| lec.h | ||
| lec_arpc.h | ||
| Makefile | ||
| mpc.c | ||
| mpc.h | ||
| mpoa_caches.c | ||
| mpoa_caches.h | ||
| mpoa_proc.c | ||
| pppoatm.c | ||
| proc.c | ||
| protocols.h | ||
| pvc.c | ||
| raw.c | ||
| resources.c | ||
| resources.h | ||
| signaling.c | ||
| signaling.h | ||
| svc.c | ||