From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f42.google.com (mail-dl1-f42.google.com [74.125.82.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D675C823DD for ; Wed, 28 Jan 2026 12:19:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769602771; cv=none; b=dz7DhSjbz3lFPpOWF5FHO5DoNClUGMnbudIDbWZR7eZ5L/XU0mvT60cUnVtBOjvTAoF6pq0FISauRONAoe3wHcear40k+RvYC2qE0GMCO/bPhTDA+tVa9+KYiuVG4fp4q8jAJycE/m7vlK4TVK83O0Uj3V+kMzIpxjHCcXOslk8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769602771; c=relaxed/simple; bh=JdR2rSf0erIkSsIXKJCpS46c4lCkQLcL84h8P8VBYHk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZHakyuK0ppGfmIRy2wlxJ1jO0wENjOnuosdCTAWGC8bYM5JDw80qie/ZUbIQvPtz3zLN3OOL8hdEPIYOXY4VsPSWJLjLqOgkaABUGxGsabOnUvj2r+1mmGRuYwJOPpElb4GiHiB2Gdru3K9JtId0XvtDbdxa3l781qqefXC33Sk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=a1hVc+Mu; arc=none smtp.client-ip=74.125.82.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="a1hVc+Mu" Received: by mail-dl1-f42.google.com with SMTP id a92af1059eb24-12331482b8fso847208c88.1 for ; Wed, 28 Jan 2026 04:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769602769; x=1770207569; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=MRGkP5+YEwarPAqoRUSfhM+YSpi6qiSMYzget0HX3O0=; b=a1hVc+MuX6yWLLvsg32JUOuh4Hr8PuUDjcuP60C7Wn2idqYGIbXcGWd43VYgWD36UU 9mfkeV4noAqZBflWpdwSeFzjn9elpi1MBFPfbpHjpCafknkNkkRZ9U/9qHukn2+iq2Tu 7BOFbkT6L6X4pWj7feziyaqWQw81JNDEd8Kwq+gfSggbKkOFXAMHgR7d+EWqDs1Ga3q9 m4UNFYGDsd3H3yVDsMzhshl5rSau+cnCFgdCrncJW5ZsTt0pcO/IvsPBpTVpj9yR1Pv8 D8GK4fS+uYqOTrCk2LXkmavgCdutF8YSioVn1gjoy6nteba0TJblCvOpuBI4zbRYv8vX zO8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769602769; x=1770207569; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=MRGkP5+YEwarPAqoRUSfhM+YSpi6qiSMYzget0HX3O0=; b=Ma9UkR79jQ30HSZUElM1oecU4Cl+nEhOTv/+tBz8KtMaBlBazacyIARUHTJ7l6ixLD 9BJiFrP6UV90vSIc2rqlTrHP9YXzZYoMbA+tEDf25gpv1vl8kygZUzPKgH1oIbqthMVe V1Yu3aNDB0iCUHxJkRThTA74dzyVbWgUwUTzivTeIpb10qbxnqtXHQSQfgGB3PhcnHhd RYujXqOmAkWg/sMFGbaGBjBgYgNWk9aYjJMXkwHgPEFP+WP0LuRipN10zBCSSVDWeqQP 0tgf1s1yT2hQoM9vTC9awvMa5NKECwPn70CRo43c8pOFws9VRhrtMcfA3wMQMRsmLLWZ tDZw== X-Forwarded-Encrypted: i=1; AJvYcCVEt+qHZobxKXdpsjZ6hIKXhX/WvqHx9UQpCnJw4qL7vMTecrYlvBsOc79mr/yjZFTdbzFeus0Da7KC0+Q=@vger.kernel.org X-Gm-Message-State: AOJu0YyBYKErOCKweBFtQGF3zJZSOe3umefBpbLaF0A8+RKJe0udLI0k jtt+c3VA3fNy8Dr24gg1WKSUKsGoWwGTIQNxT1ELW9glwPeNsIvhfzmI X-Gm-Gg: AZuq6aJqp4acdONzNj5/8jichtRDHNctLvjRigG/R0QZLOZeKJ+cvBTOW7VgWdgRYto JLElSK/Kww+eilA+y6qqzoznN7QFaEyEZ1zbi+xHR1piL0aEbz5elsA1BxO1QqvMq669cPfQIHv 0koDo0Oy+i2ZL2FBYExdM+XF/qPEy4Q0cJzjYJlOriiV1lUbiPV66jYjUvqVrIk0SraSqWaQc4e o1wOuIOwSpZqt8CTrNpl0zfQTpgzY6fEIeiZWXSJhMrUBxO6jLU+BSQykp66W/sZS9bWC0jZipp J8/WtQEyctHY6UAnQseBY4WhCVOD72x6rRYBftXh8EgiGP3PihZURJonGwDclggGIq0EvLi3n3w TZgRdHr0E46XZ+eexDNYCeu40M2uxOnFuPLnckp1Wxa21p9UV3WXpM2qJBM3oyRZYVOzKbTME55 1WG7E= X-Received: by 2002:a05:7301:1016:b0:2ae:5fb4:c5f1 with SMTP id 5a478bee46e88-2b78d9e810amr3201379eec.22.1769602768785; Wed, 28 Jan 2026 04:19:28 -0800 (PST) Received: from debian ([74.48.213.230]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2b7a1af88c4sm2268876eec.31.2026.01.28.04.19.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jan 2026 04:19:28 -0800 (PST) From: Qiliang Yuan To: kuniyu@google.com Cc: brauner@kernel.org, davem@davemloft.net, edumazet@google.com, horms@kernel.org, jlayton@kernel.org, kuba@kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, realwujing@gmail.com, sd@queasysnail.net, yuanql9@chinatelecom.cn Subject: Re: [PATCH net-next v3] netns: optimize netns cleaning by batching unhash_nsid calls Date: Wed, 28 Jan 2026 07:19:16 -0500 Message-ID: <20260128121921.1761236-1-realwujing@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Kuniyuki, On Tue, Jan 27, 2026 at 6:05 PM Kuniyuki Iwashima wrote: > > On Tue, Jan 27, 2026 at 5:22 PM Qiliang Yuan wrote: > > > > Currently, unhash_nsid() scans the entire net_namespace_list for each > > netns in a destruction batch during cleanup_net(). This leads to > > O(M_batch * N_system * M_nsids) complexity, where M_batch is the > > destruction batch size, N_system is the total number of namespaces, > > and M_nsids is the number of IDs in each IDR. > > > > Reduce the complexity to O(N_system * M_nsids) by introducing an > > 'is_dying' flag to mark namespaces being destroyed. This allows > > unhash_nsid() to perform a single-pass traversal over the system's > > namespaces. In this pass, for each survivor namespace, iterate > > through its netns_ids and remove any mappings that point to a marked > > namespace, effectively eliminating the M_batch multiplier. > > > > Signed-off-by: Qiliang Yuan > > Signed-off-by: Qiliang Yuan > > Why two SOBs with the same person ? - Signed-off-by: Qiliang Yuan (Personal email) - Signed-off-by: Qiliang Yuan (Work email) My work email often has trouble receiving external mailing list replies, so I've included both to ensure I don't miss any feedback and to properly attribute the work. The v8 version should have everything matching correctly now. > > diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c > > index a6e6a964a287..50fdd4f9bb3b 100644 > > --- a/net/core/net_namespace.c > > +++ b/net/core/net_namespace.c > > @@ -624,9 +624,10 @@ void net_ns_get_ownership(const struct net *net, kuid_t *uid, kgid_t *gid) > > } > > EXPORT_SYMBOL_GPL(net_ns_get_ownership); > > > > -static void unhash_nsid(struct net *net, struct net *last) > > +static void unhash_nsid(struct net *last) > > { > > struct net *tmp; > > + > > /* This function is only called from cleanup_net() work, > > * and this work is the only process, that may delete > > * a net from net_namespace_list. So, when the below > > @@ -636,20 +637,34 @@ static void unhash_nsid(struct net *net, struct net *last) > > for_each_net(tmp) { > > int id; > > > > - spin_lock(&tmp->nsid_lock); > > - id = __peernet2id(tmp, net); > > - if (id >= 0) > > - idr_remove(&tmp->netns_ids, id); > > - spin_unlock(&tmp->nsid_lock); > > - if (id >= 0) > > - rtnl_net_notifyid(tmp, RTM_DELNSID, id, 0, NULL, > > - GFP_KERNEL); > > + for (id = 0; ; id++) { > > Doesn't this rather slow down in a common case where > init_net has ids for other netns since it is never dismantled ? Yes, you're right. In the original code, we only scanned 'tmp' for specific 'net' which was being killed. Now we are scanning all IDs in 'tmp' to find any dying peers. If 'tmp' (like init_net) has many long-lived netns IDs, we end up iterating through them even if none of them are dying. To address this and avoid the overhead, I can use idr_for_each() with a callback to find and collect dying IDs, or keep the O(M_batch) outer loop but optimize the inner part if it's truly problematic. However, given that this is the cleanup path, I thought the batching benefit (N_system vs M_batch * N_system) would outweigh the per-netns IDR scan. I'll revert to a more efficient iteration or use idr_for_each() to handle this gracefully in v4. Thanks, Qiliang