Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1266561pxa; Thu, 20 Aug 2020 07:07:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxs49nwMszJ3+rInYdX/gDD2VtTFEjtGxKS11pv3kyFQcORnsjbd7LClY4GKN+ITUsyXRHH X-Received: by 2002:a17:906:7f0e:: with SMTP id d14mr3447352ejr.400.1597932463747; Thu, 20 Aug 2020 07:07:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597932463; cv=none; d=google.com; s=arc-20160816; b=gbVLQo4LxjoHZZLTV2mYGEIdzrIWQSTSKfAcfaTureZVm8NoQDTfG8kh+eKybETnIL dfcDdg8Z3a1/rhT83S5z8Qt2ZEBasyN1BH4OL4vxvdnuATHKNxagvD+NEf1ssULBfPkk zmOSt5A8yCAK1s59lD/cbrHfaZb9lg5mhahGe7duMwv1csGbfqSXE46iYIwWUUzIuCqv 5T86/Ej0UodFPJi3pYY3weVIR6rmV/ZWDUtZWFWCsK3ATPVBTp8OsXu+1ARByn0IUA/V 9254ldwmINlhV4qmzEyiEfthA+IHZQfyFUDvMO8mBZg/gYHgmEF8KCuRfH2LRKfqVq6x nYeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=7V8Nr2ZLqIB6Fm+9YdweCl6lFef8zjHx+W/eb65CZWQ=; b=vXLLBMvAsvPGHsS7mh5vorZMCc7ilTsECJU4vKbA6mKS/NUn6v1VgVjwFFyGgMNZZT VRnJx8HXU6qypMgPO3AczFchtMBY9xZ6dZ09qcrq04V3eN4B5Olw0sR1ZlqNI62W2JVG haw2btMH5KsgmUglL+74gI7R3I/3nklJPalybConXlbhHVnnDEcYkr1ZNU3HaNB7qHoT YmbEdG0nat3w6DH9Yh9BB40fJWP/ezilpxSol+Bje9KOpQEtCE0BW+hdZAt9HOj/YpCJ 5STGZELgo75DGQjyp8de+VQtzvoVRAzbCV2EHRaDSbyni8GiiIdNV4IiIS67sYZsT0yQ dD3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OefLEHD7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b31si1329005edf.456.2020.08.20.07.07.19; Thu, 20 Aug 2020 07:07:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OefLEHD7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727791AbgHTOG1 (ORCPT + 99 others); Thu, 20 Aug 2020 10:06:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42758 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728107AbgHTOC2 (ORCPT ); Thu, 20 Aug 2020 10:02:28 -0400 Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77BF9C061385 for ; Thu, 20 Aug 2020 07:02:28 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id k12so1545050otr.1 for ; Thu, 20 Aug 2020 07:02:28 -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=7V8Nr2ZLqIB6Fm+9YdweCl6lFef8zjHx+W/eb65CZWQ=; b=OefLEHD7/gsOkGowHqibgIn2BvXcvuSIL22NvNVC0MKMv5EA1gcTDshdsOrsDs6R9v tTBVEFdNJQzdjBtZFcFFOolTJQv6VHaN/ASR/ZWU/Vnct1lKzJOXm/QY4/cW47+Rf24o vG7ZfKsIiBMwzpeADcDKuYghAGbkKoLTOIuziuJDtDZHeX9Az+QoghHLruquO3FLGu9J dhE4yJGGdbNtSP2y9SGBr/zu5pwOLpX4PVQqgdir1/JPbfDUNl2FtZdCw0yUtJCv6pis 5NnlORyNniDGHK6wXeynz+OE7rcy/1+jngd7A5uPpyV0Cuy44m/qZMlsEh/FBRJeoukR OGGw== 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=7V8Nr2ZLqIB6Fm+9YdweCl6lFef8zjHx+W/eb65CZWQ=; b=WOP1Wc1R+AtqutZhnK1rwbFR5Un4Z+zd+fa+PqWZ3xktHPew76QsZ0oqE0nQ21XlsR goyx9/DHhRTkvv8+EMdS1XtiQrtbn8NdcGvKANkdiY8kjTrX1oFl1SQ5a38sUZa2fVtL KBudG8n9jlCPqU4UarO2LoFk3vcRYQ+nKsP7b9a323RzoLkf/5fZZ+U9N5ifpmqDAYAW xHycggJ0fmnfNjyoNUihQkYuWRmTs0T61Sx6wmbA0Lcl2/UVYX5G+iqQgMcneR2j7zTE vKkPHZYZr+xrL/rfl+TZ/tLv//KK2GtCG0Onkv693StDZ+eATR0/RPMMXHhg7ajz5EFm j++Q== X-Gm-Message-State: AOAM531YMdU/HrVkgA/HuhojyAqJtSEwn+uIeuABFkuLtpVJ0G18Wtdw wQd6S1G5l365Pger5ge/1Si8tUNEmeb6fw7UaQpY7x2fX5F6Pg== X-Received: by 2002:a9d:20c4:: with SMTP id x62mr2038263ota.99.1597932147885; Thu, 20 Aug 2020 07:02:27 -0700 (PDT) MIME-Version: 1.0 References: <1597061872-58724-1-git-send-email-xlpang@linux.alibaba.com> In-Reply-To: <1597061872-58724-1-git-send-email-xlpang@linux.alibaba.com> From: Pekka Enberg Date: Thu, 20 Aug 2020 17:02:10 +0300 Message-ID: Subject: Re: [PATCH v2 0/3] mm/slub: Fix count_partial() problem To: Xunlei Pang Cc: Vlastimil Babka , Christoph Lameter , Wen Yang , Roman Gushchin , Konstantin Khlebnikov , David Rientjes , LKML , "linux-mm@kvack.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 10, 2020 at 3:18 PM Xunlei Pang wrote: > > v1->v2: > - Improved changelog and variable naming for PATCH 1~2. > - PATCH3 adds per-cpu counter to avoid performance regression > in concurrent __slab_free(). > > [Testing] > On my 32-cpu 2-socket physical machine: > Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz > perf stat --null --repeat 10 -- hackbench 20 thread 20000 > > == original, no patched > 19.211637055 seconds time elapsed ( +- 0.57% ) > > == patched with patch1~2 > Performance counter stats for 'hackbench 20 thread 20000' (10 runs): > > 21.731833146 seconds time elapsed ( +- 0.17% ) > > == patched with patch1~3 > Performance counter stats for 'hackbench 20 thread 20000' (10 runs): > > 19.112106847 seconds time elapsed ( +- 0.64% ) > > > Xunlei Pang (3): > mm/slub: Introduce two counters for partial objects > mm/slub: Get rid of count_partial() > mm/slub: Use percpu partial free counter > > mm/slab.h | 2 + > mm/slub.c | 124 +++++++++++++++++++++++++++++++++++++++++++------------------- > 2 files changed, 89 insertions(+), 37 deletions(-) We probably need to wrap the counters under CONFIG_SLUB_DEBUG because AFAICT all the code that uses them is also wrapped under it. An alternative approach for this patch would be to somehow make the lock in count_partial() more granular, but I don't know how feasible that actually is. Anyway, I am OK with this approach: Reviewed-by: Pekka Enberg You still need to convince Christoph, though, because he had objections over this approach. - Pekka