From patchwork Tue Oct 27 13:44:57 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 312610 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B93FC56202 for ; Tue, 27 Oct 2020 15:28:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 07C5622202 for ; Tue, 27 Oct 2020 15:28:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603812516; bh=bYNbhbqM39yeoVrh7stHZh+bz3NNfwEA99baQdTdKyQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=BVOoRfGuc74td6lcRxAhDUOH03lATD+gs0kbRE8Dp9YW1Q2suV83VhtrD5J2O5acU L4EaootGvWj6N1UFBCmKIxyt0h3ziiYN2PYMBhvbmg/iDzNQ5qjCtZzjZPk9J1FvPO f7iCax7M5nQKIWTxC0a2Xb752TfFUG/0e78htKis= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1798523AbgJ0P2b (ORCPT ); Tue, 27 Oct 2020 11:28:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:35494 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1796987AbgJ0PU6 (ORCPT ); Tue, 27 Oct 2020 11:20:58 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 437A12064B; Tue, 27 Oct 2020 15:20:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603812058; bh=bYNbhbqM39yeoVrh7stHZh+bz3NNfwEA99baQdTdKyQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dcTtiVEkNOkxwvNBXSnaJdwjS4/pY0oE5zCnBtDGStSY7mUf8V0LEphwiS568eTos k007vhmy6nXP7cFJ9c/1tyn/hMltI7D61VyG/QqD90V7tMe56wtOYvx/gZHzB0I/eA xEecuAVfTdCjLZJfaCO3gv68wdnGwtXZqesXU4Lo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ido Schimmel , Jesse Brandeburg , David Ahern , Nikolay Aleksandrov , Jakub Kicinski Subject: [PATCH 5.9 047/757] nexthop: Fix performance regression in nexthop deletion Date: Tue, 27 Oct 2020 14:44:57 +0100 Message-Id: <20201027135452.747433967@linuxfoundation.org> X-Mailer: git-send-email 2.29.1 In-Reply-To: <20201027135450.497324313@linuxfoundation.org> References: <20201027135450.497324313@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Ido Schimmel [ Upstream commit df6afe2f7c19349de2ee560dc62ea4d9ad3ff889 ] While insertion of 16k nexthops all using the same netdev ('dummy10') takes less than a second, deletion takes about 130 seconds: # time -p ip -b nexthop.batch real 0.29 user 0.01 sys 0.15 # time -p ip link set dev dummy10 down real 131.03 user 0.06 sys 0.52 This is because of repeated calls to synchronize_rcu() whenever a nexthop is removed from a nexthop group: # /usr/share/bcc/tools/offcputime -p `pgrep -nx ip` -K ... b'finish_task_switch' b'schedule' b'schedule_timeout' b'wait_for_completion' b'__wait_rcu_gp' b'synchronize_rcu.part.0' b'synchronize_rcu' b'__remove_nexthop' b'remove_nexthop' b'nexthop_flush_dev' b'nh_netdev_event' b'raw_notifier_call_chain' b'call_netdevice_notifiers_info' b'__dev_notify_flags' b'dev_change_flags' b'do_setlink' b'__rtnl_newlink' b'rtnl_newlink' b'rtnetlink_rcv_msg' b'netlink_rcv_skb' b'rtnetlink_rcv' b'netlink_unicast' b'netlink_sendmsg' b'____sys_sendmsg' b'___sys_sendmsg' b'__sys_sendmsg' b'__x64_sys_sendmsg' b'do_syscall_64' b'entry_SYSCALL_64_after_hwframe' - ip (277) 126554955 Since nexthops are always deleted under RTNL, synchronize_net() can be used instead. It will call synchronize_rcu_expedited() which only blocks for several microseconds as opposed to multiple milliseconds like synchronize_rcu(). With this patch deletion of 16k nexthops takes less than a second: # time -p ip link set dev dummy10 down real 0.12 user 0.00 sys 0.04 Tested with fib_nexthops.sh which includes torture tests that prompted the initial change: # ./fib_nexthops.sh ... Tests passed: 134 Tests failed: 0 Fixes: 90f33bffa382 ("nexthops: don't modify published nexthop groups") Signed-off-by: Ido Schimmel Reviewed-by: Jesse Brandeburg Reviewed-by: David Ahern Acked-by: Nikolay Aleksandrov Link: https://lore.kernel.org/r/20201016172914.643282-1-idosch@idosch.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman --- net/ipv4/nexthop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/ipv4/nexthop.c +++ b/net/ipv4/nexthop.c @@ -842,7 +842,7 @@ static void remove_nexthop_from_groups(s remove_nh_grp_entry(net, nhge, nlinfo); /* make sure all see the newly published array before releasing rtnl */ - synchronize_rcu(); + synchronize_net(); } static void remove_nexthop_group(struct nexthop *nh, struct nl_info *nlinfo)