Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp2366479ybi; Thu, 18 Jul 2019 07:19:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqwSkyy2xRhXuHYWLX86v3s0nj5sfE2VLKUwZaCJsn2v3mqYEpteJ8k1QznI+Vpg0DnIMSR5 X-Received: by 2002:a63:2148:: with SMTP id s8mr46967616pgm.336.1563459597168; Thu, 18 Jul 2019 07:19:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563459597; cv=none; d=google.com; s=arc-20160816; b=IGAe/+F8UAqEhh4nj5gRF50IkAWxE+WGNBVp2PPu3Pkb2VYKyowt9TI2SZg8emy6du hQgJcWjkUF5QbjRdRmteR+AKb6kyrPOn7eWALylM23Juhq9AIYdK/eEb34NYc6CW3fCp aksMhV0m2R3n1FSPfrtrWz0QEGG/6m/nlJ7Wv4lB6n+C/+Sni1ek/wCp6+Nv+k9j9jye lsXVAbGqWRbrVsmMvf36zP/45WbF7b2FGSJs0PZM4iW0aMzV0bzBp4Nq7xmP0S11m4QF RNDJLHM7V0eGD9Hdz5II4QkBBh9HlPMcO7YHiLScaTvBtFVBOlYi30+ZboOQulKnTPpY MO8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=cENc9ECUtRfRkbTKqFB9awrFgZgOTCUX9BEhL02zdac=; b=zMbMpqjnEpUKNDdP13yR22jcdQ9f6QFHCFwAjKxxzND54RRvmowjrk8gM80R/qk5V6 J2Pdgs3QxZ32wBZHzaZN8PTcG7IhrgcBaDSBuEB4E8BpLhiXN1JSlSDvO/te2576+xWQ zwjfgdIcdJhK0H/qoM72pNVIteBusDDot8qN2xz9fHDJmJE2AEElZb8gwltv8bAM3wiR 9LNJdWuXjKI4nX+v24O61H5c7wUT0tKhnxRAI00EOQlZ/Bwk8eoCeNrTuE5dukuADLv4 QmgQ1ra94TWfJny9+WDDTviXAy3lv/yW+Xdse3KWbr/ojkVi1uIhcfCnd9Eudd1qet3a jGDw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k4si439030pgq.293.2019.07.18.07.19.40; Thu, 18 Jul 2019 07:19:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390663AbfGRORX convert rfc822-to-8bit (ORCPT + 99 others); Thu, 18 Jul 2019 10:17:23 -0400 Received: from cmccmta3.chinamobile.com ([221.176.66.81]:2113 "EHLO cmccmta3.chinamobile.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390356AbfGRORX (ORCPT ); Thu, 18 Jul 2019 10:17:23 -0400 Received: from spf.mail.chinamobile.com (unknown[172.16.121.1]) by rmmx-syy-dmz-app12-12012 (RichMail) with SMTP id 2eec5d307f28e2e-a11f6; Thu, 18 Jul 2019 22:16:09 +0800 (CST) X-RM-TRANSID: 2eec5d307f28e2e-a11f6 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from [10.0.0.249] (unknown[112.22.251.180]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee15d307f26c3f-095a6; Thu, 18 Jul 2019 22:16:09 +0800 (CST) X-RM-TRANSID: 2ee15d307f26c3f-095a6 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [net-next 1/2] ipvs: batch __ip_vs_cleanup From: Haishuang Yan In-Reply-To: Date: Thu, 18 Jul 2019 22:16:05 +0800 Cc: "David S. Miller" , Pablo Neira Ayuso , Simon Horman , netdev@vger.kernel.org, lvs-devel@vger.kernel.org, linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: <8441EA26-E197-4F40-A6D7-5B7D59AA7F7F@cmss.chinamobile.com> References: <1563031186-2101-1-git-send-email-yanhaishuang@cmss.chinamobile.com> <1563031186-2101-2-git-send-email-yanhaishuang@cmss.chinamobile.com> To: Julian Anastasov X-Mailer: Apple Mail (2.3273) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On 2019??7??16??, at ????4:39, Julian Anastasov wrote: > > > Hello, > > On Sat, 13 Jul 2019, Haishuang Yan wrote: > >> It's better to batch __ip_vs_cleanup to speedup ipvs >> connections dismantle. >> >> Signed-off-by: Haishuang Yan >> --- >> include/net/ip_vs.h | 2 +- >> net/netfilter/ipvs/ip_vs_core.c | 29 +++++++++++++++++------------ >> net/netfilter/ipvs/ip_vs_ctl.c | 13 ++++++++++--- >> 3 files changed, 28 insertions(+), 16 deletions(-) >> >> diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h >> index 3759167..93e7a25 100644 >> --- a/include/net/ip_vs.h >> +++ b/include/net/ip_vs.h >> @@ -1324,7 +1324,7 @@ static inline void ip_vs_control_del(struct ip_vs_conn *cp) >> void ip_vs_control_net_cleanup(struct netns_ipvs *ipvs); >> void ip_vs_estimator_net_cleanup(struct netns_ipvs *ipvs); >> void ip_vs_sync_net_cleanup(struct netns_ipvs *ipvs); >> -void ip_vs_service_net_cleanup(struct netns_ipvs *ipvs); >> +void ip_vs_service_nets_cleanup(struct list_head *net_list); >> >> /* IPVS application functions >> * (from ip_vs_app.c) >> diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c >> index 46f06f9..b4d79b7 100644 >> --- a/net/netfilter/ipvs/ip_vs_core.c >> +++ b/net/netfilter/ipvs/ip_vs_core.c >> @@ -2402,18 +2402,23 @@ static int __net_init __ip_vs_init(struct net *net) >> return -ENOMEM; >> } >> >> -static void __net_exit __ip_vs_cleanup(struct net *net) >> +static void __net_exit __ip_vs_cleanup_batch(struct list_head *net_list) >> { >> - struct netns_ipvs *ipvs = net_ipvs(net); >> - >> - ip_vs_service_net_cleanup(ipvs); /* ip_vs_flush() with locks */ >> - ip_vs_conn_net_cleanup(ipvs); >> - ip_vs_app_net_cleanup(ipvs); >> - ip_vs_protocol_net_cleanup(ipvs); >> - ip_vs_control_net_cleanup(ipvs); >> - ip_vs_estimator_net_cleanup(ipvs); >> - IP_VS_DBG(2, "ipvs netns %d released\n", ipvs->gen); >> - net->ipvs = NULL; >> + struct netns_ipvs *ipvs; >> + struct net *net; >> + LIST_HEAD(list); >> + >> + ip_vs_service_nets_cleanup(net_list); /* ip_vs_flush() with locks */ >> + list_for_each_entry(net, net_list, exit_list) { > > How much faster is to replace list_for_each_entry in > ops_exit_list() with this one. IPVS can waste time in calls > such as kthread_stop() and del_timer_sync() but I'm not sure > we can solve it easily. What gain do you see in benchmarks? Hi, As the following benchmark testing results show, there is a little performance improvement: $ cat add_del_unshare.sh #!/bin/bash for i in `seq 1 100` do (for j in `seq 1 40` ; do unshare -n ipvsadm -A -t 172.16.$i.$j:80 >/dev/null ; done) & done wait; grep net_namespace /proc/slabinfo Befor patch: $ time sh add_del_unshare.sh net_namespace 4020 4020 4736 6 8 : tunables 0 0 0 : slabdata 670 670 0 real 0m8.086s user 0m2.025s sys 0m36.956s After patch: $ time sh add_del_unshare.sh net_namespace 4020 4020 4736 6 8 : tunables 0 0 0 : slabdata 670 670 0 real 0m7.623s user 0m2.003s sys 0m32.935s > >> + ipvs = net_ipvs(net); >> + ip_vs_conn_net_cleanup(ipvs); >> + ip_vs_app_net_cleanup(ipvs); >> + ip_vs_protocol_net_cleanup(ipvs); >> + ip_vs_control_net_cleanup(ipvs); >> + ip_vs_estimator_net_cleanup(ipvs); >> + IP_VS_DBG(2, "ipvs netns %d released\n", ipvs->gen); >> + net->ipvs = NULL; >> + } >> } > > Regards > > -- > Julian Anastasov >