[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1284128679.24675.38.camel@edumazet-laptop>
Date: Fri, 10 Sep 2010 16:24:39 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: nicolas.dichtel@...nd.com
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH] ipv4: release dev refcnt early when destroying
inetdev
Le vendredi 10 septembre 2010 à 15:35 +0200, Nicolas Dichtel a écrit :
> Hi all,
>
> We got a scalability problem when we try to remove a lot of virtual interfaces.
> After analysis, we found that a refcnt on a device was released too late.
> Here is a proposal patch. If we are not missing something, the refcnt can be
> release before call_rcu(). In IPv6, this is already the case.
>
> Comments are welcome.
>
>
> Regards,
> Nicolas
> pièce jointe différences entre fichiers
> (0001-ipv4-release-dev-refcnt-early-when-destroying-inetd.patch)
> From 6fe291ff56b1f94599dfaa57dfb0ed4c168b603f Mon Sep 17 00:00:00 2001
> From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
> Date: Fri, 10 Sep 2010 14:52:15 +0200
> Subject: [PATCH] ipv4: release dev refcnt early when destroying inetdev
>
> When a virtual device is removed, refcnt on dev is released
> after rcu barrier, hence we fall always in the msleep(250)
> of netdev_wait_allrefs(). This causes a long delay when
> a lot of interfaces are removed.
> Refcnt can be released before this rcu barrier, this allows
> to accelerate the removing of virtual interfaces.
>
> Test of removing 50 ipip tunnel interfaces:
> Before the patch:
> real 0m12.804s
> user 0m0.020s
> sys 0m0.000s
>
> After the patch:
> real 0m0.988s
> user 0m0.004s
> sys 0m0.016s
>
> Signed-off-by: Wang Xuefu <xuefu.wang@...nd.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@...nd.com>
> ---
This is a well known problem, (many patches were sent some months ago)
but your patch is not the right solution.
As long as the idev is not yet freed, it can be used and we need to
access idev->dev
--
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