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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 EBB95C433E2 for ; Tue, 7 Jul 2020 15:25:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A61232078D for ; Tue, 7 Jul 2020 15:25:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DhKd6Ea+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A61232078D 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 47C848D0024; Tue, 7 Jul 2020 11:25:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 452888D0014; Tue, 7 Jul 2020 11:25:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 341E08D0024; Tue, 7 Jul 2020 11:25:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id 1B6B78D0014 for ; Tue, 7 Jul 2020 11:25:29 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CF51D1EE6 for ; Tue, 7 Jul 2020 15:25:28 +0000 (UTC) X-FDA: 77011653936.02.cup35_460f5c126eb5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id 38A5930001592A4B for ; Tue, 7 Jul 2020 15:24:03 +0000 (UTC) X-HE-Tag: cup35_460f5c126eb5 X-Filterd-Recvd-Size: 5119 Received: from mail-qk1-f196.google.com (mail-qk1-f196.google.com [209.85.222.196]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Tue, 7 Jul 2020 15:24:03 +0000 (UTC) Received: by mail-qk1-f196.google.com with SMTP id c30so34598410qka.10 for ; Tue, 07 Jul 2020 08:24:03 -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=3Txgzoid44mqUrO9velpnvNnz2jII+44h3kdWBj9Cc4=; b=DhKd6Ea+KrKdh3mxPFxa58dg9l3ChgyupBfwMp6hpUaKFKyTmjRsMo9nBZYfcGRz+E RNnS00Snbrv9MRHdVkLMxAr3D4nQCFXxCZEdS0Au2PYimd2d9l0cyT0gij1BO+CuH2ms PLEtRAafi8TyWezJn8Rt6xLQQ0vwZUZF1T+JpURMgO1AUUp6bNUf9mTmr7YgZ6wdw1Lv EfDpvFqSCcnTJtlNskKECRHBaC8pHDhMmErXmMPxlfM99Ezh82KTZZnJR3hXZyweB8Cf CUHYjR+QOLll2iVMY6cH6H2Tibx+OYd3ql4ciOg2spcnO+c7LfUc4H5bKbiV8jFISjOZ ZI8Q== 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=3Txgzoid44mqUrO9velpnvNnz2jII+44h3kdWBj9Cc4=; b=dNG0B4wRwAhFBKOusxP1ot+eV8SfRQ/xQTmA5+rS1v+V1ltHO/4YtYkyVuCSWEaDGQ HIuE4kNsHNsv/gINBtazVcVZVwy9IzbLnwqzwIXkBpchYuHW9Oa/LziGaiVSAW59wfIN 4jcsQHZljbUStJvQ1PFn1Zw9vtuwIMms9N4K8d73wGx2p/RMQ2WvtTZd0hEc7Y1AavPz 4K2LSjhd2FRysyUps6hY6y121+gN0XweITjtcu7GLWKv0//a7tDYJYJ/HYfO4+4Ka2sm KhddsU2wWSa3kRR9DQzTrL6muG+ZCM4XUoNoc6VPJ+NkAhpksowiQe6cViYgehI026We 8JGQ== X-Gm-Message-State: AOAM533NNSrSusJDgXbNDP4+17oi/WV70a7fME5Z7o11jj2CdUZ7mlS7 WTSVHe4XbgzHhEfe09PjXGEUw11aq+uguWHWS3zLk81Q X-Google-Smtp-Source: ABdhPJwbplgzxlBYHXfTN2xECGmsIRTvhHTgN5d35KPNchNTQmeaGxVUXVAUD6N02REyY+wBPKN9gY1hZ/mjUn/jjVI= X-Received: by 2002:a37:4289:: with SMTP id p131mr22832369qka.28.1594135442792; Tue, 07 Jul 2020 08:24:02 -0700 (PDT) MIME-Version: 1.0 References: <1593678728-128358-1-git-send-email-xlpang@linux.alibaba.com> <7374a9fd-460b-1a51-1ab4-25170337e5f2@linux.alibaba.com> In-Reply-To: <7374a9fd-460b-1a51-1ab4-25170337e5f2@linux.alibaba.com> From: Pekka Enberg Date: Tue, 7 Jul 2020 18:23:46 +0300 Message-ID: Subject: Re: [PATCH 1/2] mm/slub: Introduce two counters for the partial objects To: Xunlei Pang Cc: Christoph Lameter , Andrew Morton , Wen Yang , Yang Shi , Roman Gushchin , "linux-mm@kvack.org" , LKML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 38A5930001592A4B X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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: Hi! (Sorry for the delay, I missed your response.) On Fri, Jul 3, 2020 at 12:38 PM xunlei wrote: > > On 2020/7/2 PM 7:59, Pekka Enberg wrote: > > On Thu, Jul 2, 2020 at 11:32 AM Xunlei Pang wrote: > >> The node list_lock in count_partial() spend long time iterating > >> in case of large amount of partial page lists, which can cause > >> thunder herd effect to the list_lock contention, e.g. it cause > >> business response-time jitters when accessing "/proc/slabinfo" > >> in our production environments. > > > > Would you have any numbers to share to quantify this jitter? I have no > > We have HSF RT(High-speed Service Framework Response-Time) monitors, the > RT figures fluctuated randomly, then we deployed a tool detecting "irq > off" and "preempt off" to dump the culprit's calltrace, capturing the > list_lock cost up to 100ms with irq off issued by "ss", this also caused > network timeouts. Thanks for the follow up. This sounds like a good enough motivation for this patch, but please include it in the changelog. > > objections to this approach, but I think the original design > > deliberately made reading "/proc/slabinfo" more expensive to avoid > > atomic operations in the allocation/deallocation paths. It would be > > good to understand what is the gain of this approach before we switch > > to it. Maybe even run some slab-related benchmark (not sure if there's > > something better than hackbench these days) to see if the overhead of > > this approach shows up. > > I thought that before, but most atomic operations are serialized by the > list_lock. Another possible way is to hold list_lock in __slab_free(), > then these two counters can be changed from atomic to long. > > I also have no idea what's the standard SLUB benchmark for the > regression test, any specific suggestion? I don't know what people use these days. When I did benchmarking in the past, hackbench and netperf were known to be slab-allocation intensive macro-benchmarks. Christoph also had some SLUB micro-benchmarks, but I don't think we ever merged them into the tree. - Pekka