From patchwork Mon Feb 8 19:32:40 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Eric Dumazet X-Patchwork-Id: 44815 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 642EFB7D1E for ; Tue, 9 Feb 2010 06:33:13 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754568Ab0BHTcr (ORCPT ); Mon, 8 Feb 2010 14:32:47 -0500 Received: from mail-bw0-f219.google.com ([209.85.218.219]:41514 "EHLO mail-bw0-f219.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753526Ab0BHTcq (ORCPT ); Mon, 8 Feb 2010 14:32:46 -0500 Received: by bwz19 with SMTP id 19so51425bwz.28 for ; Mon, 08 Feb 2010 11:32:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=vC9Q6kuGwhoypdSz8F39OlcHgttO5kS0nzAVyMY63hc=; b=sQ5iGJpLQdkn08arNt47OKyoyHW6HTnUE1tYXFuRPW9f58Z9mLHaWe26yAO12rSUwz xGqQpWzwwgB0jR+4IBF1s1TaQEzs+Vigc5d8zgqyBX11HyaeLtC35PUxpCpjaAOhutcR /brOu3BmylC6/5QzGGEJmfSbHi40G1zYzc4p8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=S72mqVg2XUZ6wQ++ftDrQTF8q+K7newrkrnTbVsJfqPOMlEDjnSmiiX/xNH1YneWjK UPvKIzodLmIiU9NjC4qVIefAMKiKth+LVRALk+mgydI0xynvvIsSRzSPXO+u2SyrSjNd SesSf6vErYbEt/nMjI3B9acV1VyUmYyUS6s/Q= Received: by 10.204.34.24 with SMTP id j24mr90736bkd.147.1265657563208; Mon, 08 Feb 2010 11:32:43 -0800 (PST) Received: from ?127.0.0.1? (gw1.cosmosbay.com [212.99.114.194]) by mx.google.com with ESMTPS id 13sm2028643bwz.10.2010.02.08.11.32.41 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Feb 2010 11:32:42 -0800 (PST) Subject: [PATCH] dst: call cond_resched() in dst_gc_task() From: Eric Dumazet To: =?UTF-8?Q?Pawe=C5=82?= Staszewski , David Miller Cc: Linux Network Development list In-Reply-To: <1265639549.3048.33.camel@edumazet-laptop> References: <4B700EC2.5090207@itcare.pl> <1265635690.3048.8.camel@edumazet-laptop> <4B7012BC.9000702@itcare.pl> <1265637067.3048.14.camel@edumazet-laptop> <4B7018DF.8060600@itcare.pl> <1265638014.3048.20.camel@edumazet-laptop> <4B701CA8.7050205@itcare.pl> <1265639549.3048.33.camel@edumazet-laptop> Date: Mon, 08 Feb 2010 20:32:40 +0100 Message-ID: <1265657560.4236.80.camel@edumazet-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Le lundi 08 février 2010 à 15:32 +0100, Eric Dumazet a écrit : > Le lundi 08 février 2010 à 15:16 +0100, Paweł Staszewski a écrit : > > > > > > Some day ago after info about route cache i was have also this info: > > > Code: fe 79 4c 00 48 85 db 74 14 48 8b 74 24 10 48 89 ef ff 13 48 83 c3 08 48 > > 83 3b 00 eb ea 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f 55 48 89 f5 53 48 > > 89 fb 48 83 ec 08 48 8b 76 18 48 2b 75 10 > > Call Trace: > > [] ? e1000_put_txbuf+0x62/0x74 > > [] ? e1000_clean_tx_irq+0xc9/0x235 > > [] ? e1000_clean+0x5c/0x21c > > [] ? net_rx_action+0x71/0x15d > > [] ? __do_softirq+0xd7/0x196 > > [] ? call_softirq+0x1c/0x28 > > [] ? dst_gc_task+0x0/0x1a7 > > [] ? call_softirq+0x1c/0x28 > > [] ? do_softirq+0x31/0x63 > > [] ? local_bh_enable_ip+0x75/0x86 > > [] ? dst_gc_task+0x0/0x1a7 > > [] ? dst_gc_task+0xce/0x1a7 > > [] ? schedule+0x82c/0x906 > > [] ? lock_timer_base+0x26/0x4b > > [] ? cache_reap+0x0/0x11d > > [] ? worker_thread+0x14c/0x1dc > > [] ? autoremove_wake_function+0x0/0x2e > > [] ? worker_thread+0x0/0x1dc > > [] ? kthread+0x79/0x81 > > [] ? kernel_thread_helper+0x4/0x10 > > [] ? kthread+0x0/0x81 > > > > > > [] ? kernel_thread_helper+0x0/0x10 > > > > > > This trace is indeed very interesting, since dst_gc_task() is run from a > work queue, and there is no scheduling point in it. > > We might need add a scheduling point in dst_gc_task() in case huge > number of entries were flushed. > David, here is the patch I sent to Pawel to solve this problem. This probaby is a stable candidate. Thanks [PATCH] dst: call cond_resched() in dst_gc_task() On some workloads, it is quite possible to get a huge dst list to process in dst_gc_task(), and trigger soft lockup detection. Fix is to call cond_resched(), as we run in process context. Reported-by: Pawel Staszewski Tested-by: Pawel Staszewski Signed-off-by: Eric Dumazet --- -- 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 diff --git a/net/core/dst.c b/net/core/dst.c index 57bc4d5..cb1b348 100644 --- a/net/core/dst.c +++ b/net/core/dst.c @@ -17,6 +17,7 @@ #include #include #include +#include #include @@ -79,6 +80,7 @@ loop: while ((dst = next) != NULL) { next = dst->next; prefetch(&next->next); + cond_resched(); if (likely(atomic_read(&dst->__refcnt))) { last->next = dst; last = dst;