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=-12.8 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL autolearn=unavailable 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 BCB93C38A24 for ; Thu, 7 May 2020 18:24:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7EE622073A for ; Thu, 7 May 2020 18:24:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="jhPrNDlf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7EE622073A Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 01AC9900003; Thu, 7 May 2020 14:24:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F0DBF900002; Thu, 7 May 2020 14:24:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E4A7B900003; Thu, 7 May 2020 14:24:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0031.hostedemail.com [216.40.44.31]) by kanga.kvack.org (Postfix) with ESMTP id CB727900002 for ; Thu, 7 May 2020 14:24:58 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 898604995F5 for ; Thu, 7 May 2020 18:24:58 +0000 (UTC) X-FDA: 76790749476.28.boot64_82b8305a4a752 X-HE-Tag: boot64_82b8305a4a752 X-Filterd-Recvd-Size: 5831 Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 May 2020 18:24:58 +0000 (UTC) Received: by mail-pf1-f196.google.com with SMTP id x2so3398169pfx.7 for ; Thu, 07 May 2020 11:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=JmY2P1v7eg8hDmhKflScuHXGXBSSsuu5HkSbuBLgbys=; b=jhPrNDlftSgnKSOz8O1RetlNzRfXH3C3YfhdTWWuEs29gIgWK6oL29IfLgxRij2kT5 OqSb4lf+u53Z+EiCqRa3fWGAu7V9mm0CBTbW37YmMf9JYi3h4YTGd10k3IDBNewcinqe 7dDWeyWF/dL60TYHDNRuvbsQevXTdHmJ7XaNo3uvfeABDRdEk9wbVj2sM0e+AYX4mcZ9 b8BY6XfajFs/tpJ/WSXmgGNm47Pm+Rrg+HiYIGgVghxFZK9X2o2zi+D14ZXH/I15mRVG 4M7CsnyyS361GYMFC0TaqeLgWRTccilxC6nuneyRmG3MugBw3NQH3ojPzA+CCGiM6U2+ 2/YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=JmY2P1v7eg8hDmhKflScuHXGXBSSsuu5HkSbuBLgbys=; b=Fiqa/+JreBuIGtt/J5Tr+4utS33r9ejw07LoqyBK6WowZcIk55XCSIYDyxcijo2/C3 ap3ifPOZa7zHMr7xuTVnX06i6oBK/Ze8zNUqoJYLZ8RK0V8tTiDC633OjZK7kE170paM V77+l/BGVYMEbPoWTCtd+8Pzo0vt7XB0RPJsWFon/d0VPHaolA6nhzTIq3O7V7ZRoY7Q 5j7tuzz5BkMWolkTUJb2NvcMBJD+e0pTkHX39RE269b/eYnwn/SArAWMXZVVukf/l4Xs vozDJZRj81ERqC79k/G34NrVKX5CEpRmHnO8iooX5VmrkgiubrzMZ27cvLye8a5DECps ceDw== X-Gm-Message-State: AGi0PuaZCsYmCi/NEa8OiOKeTsSbbkFm/Hjdb3smTUx/BkQLgPwGI5aq pX7matgQfcKRZTJz1CFS8wMFVQ== X-Google-Smtp-Source: APiQypKrgOaQyef7OD6jBNbka3s7B9VCNQ5iAd3KucwyUfrgYjNeEs2S2MZcXTYqRGwgW2iSs1Bx3g== X-Received: by 2002:a63:790a:: with SMTP id u10mr11928436pgc.126.1588875897015; Thu, 07 May 2020 11:24:57 -0700 (PDT) Received: from [2620:15c:17:3:3a5:23a7:5e32:4598] ([2620:15c:17:3:3a5:23a7:5e32:4598]) by smtp.gmail.com with ESMTPSA id x18sm5622964pfi.22.2020.05.07.11.24.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 May 2020 11:24:56 -0700 (PDT) Date: Thu, 7 May 2020 11:24:55 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Konstantin Khlebnikov cc: Qian Cai , Andrew Morton , Stephen Rothwell , LKML , Linux-MM , Christoph Lameter , Pekka Enberg , Joonsoo Kim , Roman Gushchin , Wen Yang Subject: Re: [PATCH] slub: limit count of partial slabs scanned to gather statistics In-Reply-To: Message-ID: References: <158860845968.33385.4165926113074799048.stgit@buzz> <5BAA0D82-555E-4E72-966A-A147472271D0@lca.pw> <39E953F3-BBA4-43BF-AA0D-B1BED21F9A4D@lca.pw> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Thu, 7 May 2020, Konstantin Khlebnikov wrote: > > > > To get exact count of free and used objects slub have to scan list of > > > > partial slabs. This may take at long time. Scanning holds spinlock and > > > > blocks allocations which move partial slabs to per-cpu lists and back. > > > > > > > > Example found in the wild: > > > > > > > > # cat /sys/kernel/slab/dentry/partial > > > > 14478538 N0=7329569 N1=7148969 > > > > # time cat /sys/kernel/slab/dentry/objects > > > > 286225471 N0=136967768 N1=149257703 > > > > > > > > real 0m1.722s > > > > user 0m0.001s > > > > sys 0m1.721s > > > > > > > > The same problem in slab was addressed in commit f728b0a5d72a ("mm, > > > > slab: > > > > faster active and free stats") by adding more kmem cache statistics. > > > > For slub same approach requires atomic op on fast path when object > > > > frees. > > > > > > > > Let's simply limit count of scanned slabs and print warning. > > > > Limit set in /sys/module/slub/parameters/max_partial_to_count. > > > > Default is 10000 which should be enough for most sane cases. > > > > > > > > Return linear approximation if list of partials is longer than limit. > > > > Nobody should notice difference. > > > > > > > > Signed-off-by: Konstantin Khlebnikov > > > > > > This patch will trigger the warning under memory pressure, and then makes > > > lockdep unhappy. Also, it is almost impossible tell how many > > > max_partial_to_count is sufficient from user perspective. > > Oops, my bad. Printing under this lock indeed a bad idea. > > Probably it's better to simply remove this message. > I cannot imagine situation when precise count of object matters at such scale. > If the printk is removed, then probably better to remove the max_partial_to_count param as well? I doubt it would ever be used since nothing points to it other than the kernel code now. If somebody complains about the approximation, we can (a) convince them the approximation is better than precise calculation to prevent irqs from being disabled for several seconds and (b) add it later if absolutely necessary. I notice the absence of other module_param()'s in mm/slub.c, so likely better to avoid adding special tunables like this unless absolutely necessary.