| Message ID | 20081103130303.29dd4e21@extreme |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
From: Stephen Hemminger <shemminger@vyatta.com> Date: Mon, 3 Nov 2008 13:03:03 -0800 > This patch gets about 1.25% back on tbench regression. > > My change to NAPI for multiqueue support changed the time limit on > network receive processing. Under sustained loads like tbench, this > can cause the receiver to reschedule prematurely. > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> I think I'm the guilty party that made that change to your NAPI patches. I'll apply this to net-next-2.6, thanks Stephen. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 03 Nov 2008 17:24:28 -0800 (PST) David Miller <davem@davemloft.net> wrote: > From: Stephen Hemminger <shemminger@vyatta.com> > Date: Mon, 3 Nov 2008 13:03:03 -0800 > > > This patch gets about 1.25% back on tbench regression. > > > > My change to NAPI for multiqueue support changed the time limit on > > network receive processing. Under sustained loads like tbench, this > > can cause the receiver to reschedule prematurely. > > > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> > > I think I'm the guilty party that made that change to your > NAPI patches. > > I'll apply this to net-next-2.6, thanks Stephen. Maybe you want it as part of the tbench regression recovery in 2.6.28? it seems mostly harmless. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Stephen Hemminger <shemminger@vyatta.com> Date: Mon, 3 Nov 2008 21:25:21 -0800 > On Mon, 03 Nov 2008 17:24:28 -0800 (PST) > David Miller <davem@davemloft.net> wrote: > > > I'll apply this to net-next-2.6, thanks Stephen. > > Maybe you want it as part of the tbench regression recovery in 2.6.28? > it seems mostly harmless. Maybe... I'd rather have it cook in net-next-2.6 for a while. Taking up more than a jiffie in softirq context is bordering on anti-social and could cause problems especially for RT'ish stuff. And I'm pretty sure that's why I made the change. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/net/core/dev.c 2008-11-03 11:11:44.000000000 -0800 +++ b/net/core/dev.c 2008-11-03 11:16:07.000000000 -0800 @@ -2373,7 +2373,7 @@ EXPORT_SYMBOL(__napi_schedule); static void net_rx_action(struct softirq_action *h) { struct list_head *list = &__get_cpu_var(softnet_data).poll_list; - unsigned long start_time = jiffies; + unsigned long time_limit = jiffies + 2; int budget = netdev_budget; void *have; @@ -2384,13 +2384,10 @@ static void net_rx_action(struct softirq int work, weight; /* If softirq window is exhuasted then punt. - * - * Note that this is a slight policy change from the - * previous NAPI code, which would allow up to 2 - * jiffies to pass before breaking out. The test - * used to be "jiffies - start_time > 1". + * Allow this to run for 2 jiffies since which will allow + * an average latency of 1.5/HZ. */ - if (unlikely(budget <= 0 || jiffies != start_time)) + if (unlikely(budget <= 0 || time_after(jiffies, time_limit))) goto softnet_break; local_irq_enable();
This patch gets about 1.25% back on tbench regression. My change to NAPI for multiqueue support changed the time limit on network receive processing. Under sustained loads like tbench, this can cause the receiver to reschedule prematurely. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html