From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH 0/20] Batch network namespace cleanup Date: Mon, 30 Nov 2009 16:34:54 -0800 (PST) Message-ID: <20091130.163454.192638570.davem@davemloft.net> References: Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, hadi@cyberus.ca, dlezcano@fr.ibm.com, adobriyan@gmail.com, kaber@trash.net To: ebiederm@xmission.com Return-path: Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:43818 "EHLO sunset.davemloft.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753149AbZLAAes (ORCPT ); Mon, 30 Nov 2009 19:34:48 -0500 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: From: ebiederm@xmission.com (Eric W. Biederman) Date: Sun, 29 Nov 2009 17:46:03 -0800 > Recently Jamal and Daniel perform some experiments and found that > large numbers of network namespace exiting simultaneously is very > inefficient. 24+ minutes in some configurations. The cpu overhead > was negligible but it results in long hold times of net_mutex, and > memory being consumed a long time after the last user has gone away. > > I looked into it and discovered that by batching network namespace > cleanups I can reduce the time for 4k network namespaces exiting from > 5-7 minutes in my configuration to 44 seconds. > > This patch series is my set of changes to the network namespace core > and associated cleanups to allow for network namespace batching. All applied, and assuming all of the build checks pass I'll push this out to net-next-2.6 I should look into that inet_twsk_purge performance issue you mention when tearing down a namespace. It walks the entire hash table and takes a lock for every hash chain. Eric, is it possible for us to at least slightly optimize this by doing a peek at whether the head pointer of each chain is NULL and bypass the spinlock and everything else in that case? Or is this not legal with sk_nulls? Something like: if (hlist_nulls_empty(&head->twchain)) continue; right before the 'restart' label?