From mboxrd@z Thu Jan 1 00:00:00 1970 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=-7.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 690D3C433DB for ; Mon, 15 Mar 2021 19:29:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E5D2264F2F for ; Mon, 15 Mar 2021 19:29:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E5D2264F2F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6A4336B0036; Mon, 15 Mar 2021 15:29:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 67CC26B006C; Mon, 15 Mar 2021 15:29:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 51C8D6B0070; Mon, 15 Mar 2021 15:29:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0225.hostedemail.com [216.40.44.225]) by kanga.kvack.org (Postfix) with ESMTP id 34C566B0036 for ; Mon, 15 Mar 2021 15:29:11 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D59693D0F for ; Mon, 15 Mar 2021 19:29:10 +0000 (UTC) X-FDA: 77923096860.24.4256F94 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf04.hostedemail.com (Postfix) with ESMTP id 05422185CE for ; Mon, 15 Mar 2021 19:22:38 +0000 (UTC) Received: by mail-ed1-f53.google.com with SMTP id b16so5922257eds.7 for ; Mon, 15 Mar 2021 12:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VN2QmRBHk/YVrYYtE6i8DWZ5kx35s2uQPi/cXaUiXgQ=; b=Vp5kqbATEHGH4mw9HI+4INYb82mtWw+2HS73rAo3MNyB/FnPeP29zLqLZGbCxxPUyO y+b8O+tQUKevLm3p6CJOA6h/ZwiQmJUm8LKxtco8UMWETYT3PNdlkbO37KzdK34QpDsO fHEl2isfRn0YrytxkU/z+tKkLhelm99awsyhhgSEnrblLJGUpHWd5eM6LttqJkgs5qlt LlX+47oLoR0LvML8mEJsMz0dip31J19A3QLRDImPC32RBqY2is7pQVDzG8wrjV9VYPHE udI+3+e3gRv51Rp06185TW9TQtZsGxa0KmjomixkCToZxx82dc6NN8KOf7jmbb7zkHFm rphQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VN2QmRBHk/YVrYYtE6i8DWZ5kx35s2uQPi/cXaUiXgQ=; b=sMtkdkSn72YHehz4MbRdH5tq60WDPgJ3wcIq0Hejaa4Q6faFbilXh3CgfzcTZBz13C bY7Vapxe/TJuaXfLE1vhvdH8omc4BF8wZnJKIztxHY3QYkhYfw9SM5uPx3g02AY6olzu qRyh6aAyCVVAlMBdz8nsN+AzVBGy64xW5aQ1ba678D1chbbdCZuwkPS8XjWfyKXxh6oG kvAnSOgd5yw+DkkYgrATQwqcPdZSnnJikO3DrA8lJEy9nTKHiUVk5AoiaQs07HfM8k8K MaHEDFGDDlHvwrkaaq9Dt3KS+xPz7PZENpvGQMH8pnrYUdttKbUSBYI5X8eM0JEVjwpg kNRw== X-Gm-Message-State: AOAM531fRpOriqle/TSQ51KzGkdfRXE3awFceVQG31ztWB0BZvfEBgvg FJLqx2bLOCvWaCcs+msOVbTHR8Et1tuwUNtBLPk= X-Google-Smtp-Source: ABdhPJzwr7yryQPUN4DOmOqs5fZRX8T7Bff8U6hjPQV/YJ91cnOIyROU65PTDH2aATMDeor+7YEg8Oj7ccZpx3Tz6kQ= X-Received: by 2002:a05:6402:518d:: with SMTP id q13mr31885055edd.313.1615836157714; Mon, 15 Mar 2021 12:22:37 -0700 (PDT) MIME-Version: 1.0 References: <1615303512-35058-1-git-send-email-xlpang@linux.alibaba.com> <793c884a-9d60-baaf-fab8-3e5f4a024124@suse.cz> In-Reply-To: From: Yang Shi Date: Mon, 15 Mar 2021 12:22:25 -0700 Message-ID: Subject: Re: [PATCH v3 0/4] mm/slub: Fix count_partial() problem To: Roman Gushchin Cc: Vlastimil Babka , Xunlei Pang , Christoph Lameter , Pekka Enberg , Konstantin Khlebnikov , David Rientjes , Matthew Wilcox , Shu Ming , Andrew Morton , Linux Kernel Mailing List , Linux MM , Wen Yang , James Wang , Thomas Gleixner Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: gziekmnmk4rdikxfsqt3muiwtx4zm7ub X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 05422185CE Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf04; identity=mailfrom; envelope-from=""; helo=mail-ed1-f53.google.com; client-ip=209.85.208.53 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615836158-114312 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Mar 15, 2021 at 12:15 PM Roman Gushchin wrote: > > > On Mon, Mar 15, 2021 at 07:49:57PM +0100, Vlastimil Babka wrote: > > On 3/9/21 4:25 PM, Xunlei Pang wrote: > > > count_partial() can hold n->list_lock spinlock for quite long, which > > > makes much trouble to the system. This series eliminate this problem. > > > > Before I check the details, I have two high-level comments: > > > > - patch 1 introduces some counting scheme that patch 4 then changes, could we do > > this in one step to avoid the churn? > > > > - the series addresses the concern that spinlock is being held, but doesn't > > address the fact that counting partial per-node slabs is not nearly enough if we > > want accurate in /proc/slabinfo because there are also percpu > > slabs and per-cpu partial slabs, where we don't track the free objects at all. > > So after this series while the readers of /proc/slabinfo won't block the > > spinlock, they will get the same garbage data as before. So Christoph is not > > wrong to say that we can just report active_objs == num_objs and it won't > > actually break any ABI. > > At the same time somebody might actually want accurate object statistics at the > > expense of peak performance, and it would be nice to give them such option in > > SLUB. Right now we don't provide this accuracy even with CONFIG_SLUB_STATS, > > although that option provides many additional tuning stats, with additional > > overhead. > > So my proposal would be a new config for "accurate active objects" (or just tie > > it to CONFIG_SLUB_DEBUG?) that would extend the approach of percpu counters in > > patch 4 to all alloc/free, so that it includes percpu slabs. Without this config > > enabled, let's just report active_objs == num_objs. > > It sounds really good to me! The only thing, I'd avoid introducing a new option > and use CONFIG_SLUB_STATS instead. > > It seems like CONFIG_SLUB_DEBUG is a more popular option than CONFIG_SLUB_STATS. > CONFIG_SLUB_DEBUG is enabled on my Fedora workstation, CONFIG_SLUB_STATS is off. > I doubt an average user needs this data, so I'd go with CONFIG_SLUB_STATS. I think CONFIG_SLUB_DEBUG is enabled by default on most distros since it is supposed not incur too much overhead unless specific debug (i.e. red_zone) is turned on on demand. > > Thanks! > > > > > Vlastimil > > > > > v1->v2: > > > - Improved changelog and variable naming for PATCH 1~2. > > > - PATCH3 adds per-cpu counter to avoid performance regression > > > in concurrent __slab_free(). > > > > > > v2->v3: > > > - Changed "page->inuse" to the safe "new.inuse", etc. > > > - Used CONFIG_SLUB_DEBUG and CONFIG_SYSFS condition for new counters. > > > - atomic_long_t -> unsigned long > > > > > > [Testing] > > > There seems might be a little performance impact under extreme > > > __slab_free() concurrent calls according to my tests. > > > > > > On my 32-cpu 2-socket physical machine: > > > Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz > > > > > > 1) perf stat --null --repeat 10 -- hackbench 20 thread 20000 > > > > > > == original, no patched > > > Performance counter stats for 'hackbench 20 thread 20000' (10 runs): > > > > > > 24.536050899 seconds time elapsed ( +- 0.24% ) > > > > > > > > > Performance counter stats for 'hackbench 20 thread 20000' (10 runs): > > > > > > 24.588049142 seconds time elapsed ( +- 0.35% ) > > > > > > > > > == patched with patch1~4 > > > Performance counter stats for 'hackbench 20 thread 20000' (10 runs): > > > > > > 24.670892273 seconds time elapsed ( +- 0.29% ) > > > > > > > > > Performance counter stats for 'hackbench 20 thread 20000' (10 runs): > > > > > > 24.746755689 seconds time elapsed ( +- 0.21% ) > > > > > > > > > 2) perf stat --null --repeat 10 -- hackbench 32 thread 20000 > > > > > > == original, no patched > > > Performance counter stats for 'hackbench 32 thread 20000' (10 runs): > > > > > > 39.784911855 seconds time elapsed ( +- 0.14% ) > > > > > > Performance counter stats for 'hackbench 32 thread 20000' (10 runs): > > > > > > 39.868687608 seconds time elapsed ( +- 0.19% ) > > > > > > == patched with patch1~4 > > > Performance counter stats for 'hackbench 32 thread 20000' (10 runs): > > > > > > 39.681273015 seconds time elapsed ( +- 0.21% ) > > > > > > Performance counter stats for 'hackbench 32 thread 20000' (10 runs): > > > > > > 39.681238459 seconds time elapsed ( +- 0.09% ) > > > > > > > > > Xunlei Pang (4): > > > mm/slub: Introduce two counters for partial objects > > > mm/slub: Get rid of count_partial() > > > percpu: Export per_cpu_sum() > > > mm/slub: Use percpu partial free counter > > > > > > include/linux/percpu-defs.h | 10 ++++ > > > kernel/locking/percpu-rwsem.c | 10 ---- > > > mm/slab.h | 4 ++ > > > mm/slub.c | 120 +++++++++++++++++++++++++++++------------- > > > 4 files changed, 97 insertions(+), 47 deletions(-) > > > > > >