Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp169479ybv; Sat, 22 Feb 2020 01:28:41 -0800 (PST) X-Google-Smtp-Source: APXvYqwWSD0D86cP/DZMPpMbRFMhmk1UWgQPz1s5SXjVzuOE1K3NEAFB29nciUIsmFF2vfFjISF2 X-Received: by 2002:a9d:1c9c:: with SMTP id l28mr31357110ota.210.1582363721711; Sat, 22 Feb 2020 01:28:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582363721; cv=none; d=google.com; s=arc-20160816; b=pwAOa7Hsq/SQYP5clg0Zh4zMwD7I4Kq93L2HZFqtq/lf7VZ0O/+KL1iUBy2dVFnz6o XdakOLLLpsrJ85W+Sl0TdYzJDNS+Md39fUDMhm39xWHeSE0i6tTs46uDpV9M0IgC//hn k3j1uFrc2ZCgYJ78kPyc+bMH0SaYL2A464QAUg7BEgQjjAnYtdmM57koD4LBRCsA9tpn YFUHnE0qCz4iU1Lt63wKlm7dIfr2H1ZMws4fdr0cbWBPy+zcIwTEDS6IvfH9vJ1qvvWQ ckz06x/d317eknMcddZAkoXN2k87HF4WY6kTYjYNNi8ERR3yFrPVqHoUPbT1KfjhSxo9 7cfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=kZUlOZUgyV65amCFy1OYh4Kb1ehbUGJA8kucIs/KomY=; b=wDvpN/zODm/KBSSGpraXK1kr/yEmWwnKjBD3dM6W06v29ZZs8ozB261VYpSzDWuUuT wxAydMy9gbbbmj2KQvwvK5DOGz+t6Bj1LjqpC887GAJgP2vMrhOzi2QcOOAV9zPpwXJM p1l+YPM+9Ho1fysYVh16k/ZbczFnqLGEi/4cOOXEOjvDwIfSKJXoLtZL56PLcMKaFxNG pMgvRk+lZQl9pfGdXdzhY006XjwF47YDfjD8bAswoPn27m6+3P7gVWWfUTYkw/FdCdbx MPfO8PYJgMQWHjRnOp91fcMQiUJJtu9gBY4/Uwi+WvlZz6pkkcggcyBeLkCSjm7HKmJC O9HQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e1si3026792otr.8.2020.02.22.01.28.16; Sat, 22 Feb 2020 01:28:41 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726839AbgBVJZO (ORCPT + 99 others); Sat, 22 Feb 2020 04:25:14 -0500 Received: from out30-130.freemail.mail.aliyun.com ([115.124.30.130]:47084 "EHLO out30-130.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726689AbgBVJZO (ORCPT ); Sat, 22 Feb 2020 04:25:14 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R221e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e07417;MF=wenyang@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0TqatCjt_1582363499; Received: from localhost(mailfrom:wenyang@linux.alibaba.com fp:SMTPD_---0TqatCjt_1582363499) by smtp.aliyun-inc.com(127.0.0.1); Sat, 22 Feb 2020 17:25:06 +0800 From: Wen Yang To: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton Cc: Wen Yang , Roman Gushchin , Xunlei Pang , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH] mm/slub: improve count_partial() for CONFIG_SLUB_CPU_PARTIAL Date: Sat, 22 Feb 2020 17:24:28 +0800 Message-Id: <20200222092428.99488-1-wenyang@linux.alibaba.com> X-Mailer: git-send-email 2.23.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In the cloud server scenario, reading "/proc/slabinfo" can possibily block the slab allocation on another CPU for a while, 200ms in extreme cases. If the slab object is to carry network packet, targeting the far-end disk array, it causes block IO jitter issues. This is because the list_lock, which protecting the node partial list, is taken when couting the free objects resident in that list. It introduces locking contention when the page(s) is moved between CPU and node partial lists in allocation path on another CPU. We also observed that in this scenario, CONFIG_SLUB_CPU_PARTIAL is turned on by default, and count_partial() is useless because the returned number is far from the reality. Therefore, we can simply return 0, then nr_free is also 0, and eventually active_objects == total_objects. We do not introduce any regression, and it's preferable to show the unrealistic uniform 100% slab utilization rather than some very high but incorrect value. Co-developed-by: Roman Gushchin Signed-off-by: Roman Gushchin Signed-off-by: Wen Yang Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Andrew Morton Cc: Xunlei Pang Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org --- mm/slub.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/mm/slub.c b/mm/slub.c index 17dc00e..d5b7230 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2411,14 +2411,16 @@ static inline unsigned long node_nr_objs(struct kmem_cache_node *n) static unsigned long count_partial(struct kmem_cache_node *n, int (*get_count)(struct page *)) { - unsigned long flags; unsigned long x = 0; +#ifndef CONFIG_SLUB_CPU_PARTIAL + unsigned long flags; struct page *page; spin_lock_irqsave(&n->list_lock, flags); list_for_each_entry(page, &n->partial, slab_list) x += get_count(page); spin_unlock_irqrestore(&n->list_lock, flags); +#endif return x; } #endif /* CONFIG_SLUB_DEBUG || CONFIG_SYSFS */ -- 1.8.3.1