From patchwork Tue Oct 27 13:46:30 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 307147 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=unavailable 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 177CAC388F9 for ; Tue, 27 Oct 2020 17:24:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B96932224E for ; Tue, 27 Oct 2020 17:24:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603819445; bh=bYNbhbqM39yeoVrh7stHZh+bz3NNfwEA99baQdTdKyQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=RM+Afj0vuk0kyMGVM+zkJuhyU0qftpe4YYlki42fH+CEhQ/t6LsqJ+v5B4EM4+0i2 m+wglWGQ0hSnifuBKFbTq8frioc72PggGVO+UeIJq2NqffO6h9Ct1Ap/k/Z+cgGFsr wzrmMyNKTtHYmeM3LYtBd3JYF2/LWF72VrUkWfvg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2900799AbgJ0OyQ (ORCPT ); Tue, 27 Oct 2020 10:54:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:50518 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1773048AbgJ0OvE (ORCPT ); Tue, 27 Oct 2020 10:51:04 -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 B10DE21556; Tue, 27 Oct 2020 14:51:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603810262; bh=bYNbhbqM39yeoVrh7stHZh+bz3NNfwEA99baQdTdKyQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bGQ3aBcm/GgCPWX5NubEC/pse6FwBkueILP+R+NwjG8AzBMUKyeQ3mWs4FNTwuumG rrNAhhQTDuLXPKpCjpyJIFnBAfvv/xe5rmYsZuJrn141S3EGkjQmlcsEEhqhDjsUTi 2+waSf3V37cHQfR6yokXFtdElGZ2o84FDIOrByoY= 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.8 047/633] nexthop: Fix performance regression in nexthop deletion Date: Tue, 27 Oct 2020 14:46:30 +0100 Message-Id: <20201027135524.912736526@linuxfoundation.org> X-Mailer: git-send-email 2.29.1 In-Reply-To: <20201027135522.655719020@linuxfoundation.org> References: <20201027135522.655719020@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)