Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp3558224ybf; Tue, 3 Mar 2020 08:06:16 -0800 (PST) X-Google-Smtp-Source: ADFU+vtTZQ+q7JCtd1efGsfYrao9joIho+LCtwYJNqHW5ME+9KLdfXiMqc+SCYRrDwShjuCXCjFL X-Received: by 2002:a05:6830:22c1:: with SMTP id q1mr4033533otc.370.1583251575289; Tue, 03 Mar 2020 08:06:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583251575; cv=none; d=google.com; s=arc-20160816; b=wezf9Qj/h2zBM3CXBJ2eME2TAFe90SV3cYClNEduten0QiSNoei/kwIhDU9T9/9FjU VR2bB4oc4llxk1cCX4nl8H8Dtcx0wj/EsXsDvZD+zykatcOV6tWW/NY4UL+YSLkvieas yhVniyeFjKebv3MRCz733nceNtFdvQu0qPXiojaw7IiBCZu6A0LdX9mX7bEJ3MVGIcvt b2iAZ2jJP4qEa0IhppXnR3cegs1I570N0V4Fog4c1Njh0U6oZfQVg453Zp/KFGtc3DY0 BCHWx4id5moWo/Cqxe1vYloD0bOQ6wWO0U25oaUXEeB+dnR6BYSMBF3mkwuP/V791Plp d5Fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=hSEnCLLGknl/cOSnyQQTXLKFpp3mX8lZLB+ASS54PbI=; b=BbSpH9JpFAGfMstg6bZBXC8SOcXuqhXo0iBrX3MHZnuaHwO+p43iHdu1mBHA3YcEbH D4c4S3/fxCGYd6kRftLOsDrmFDM+pXncdMYQd03TY6HmywpH4lsv1HXZUmHvU/JL0bB6 kwpRFG69VHp7DqicscNkE+dZrDIrSfSKMgoX7vJnKp96rvSOt2+ElrcTRjcRfGy+/zxR B5IH5AhwbR0b2dpjsqkpvr310TgzyxnHlotPD4PugzpwgtT+7DygB/AAHC5hgmOqh2eV E24hJt3rIjOjWs5B/mNZOpEGnkc4RNaJECTQ4uPOiTCE6pBuscu8igEEs9q7ClU+/RP0 A7yw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y14si4248694oia.61.2020.03.03.08.06.02; Tue, 03 Mar 2020 08:06:15 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730063AbgCCQFF (ORCPT + 99 others); Tue, 3 Mar 2020 11:05:05 -0500 Received: from gentwo.org ([3.19.106.255]:43296 "EHLO gentwo.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728714AbgCCQFE (ORCPT ); Tue, 3 Mar 2020 11:05:04 -0500 Received: by gentwo.org (Postfix, from userid 1002) id EACA73F1C0; Tue, 3 Mar 2020 16:05:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id E968E3EECA; Tue, 3 Mar 2020 16:05:03 +0000 (UTC) Date: Tue, 3 Mar 2020 16:05:03 +0000 (UTC) From: Christopher Lameter X-X-Sender: cl@www.lameter.com To: Roman Gushchin cc: Wen Yang , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Xunlei Pang , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/slub: improve count_partial() for CONFIG_SLUB_CPU_PARTIAL In-Reply-To: <20200227183519.GA50628@carbon.dhcp.thefacebook.com> Message-ID: References: <20200222092428.99488-1-wenyang@linux.alibaba.com> <20200224165750.GA478187@carbon.dhcp.thefacebook.com> <20200227183519.GA50628@carbon.dhcp.thefacebook.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Feb 2020, Roman Gushchin wrote: > 1) Reading /proc/slabinfo can cause latency spikes in concurrent memory allocations. > This is the problem which Wen raised initially. Ok. Maybe cache the values or do not read /proc/slabinfo? Use /sys/kernel/slab/... instead? > 2) The number of active objects as displayed in /proc/slabinfo is misleadingly > big if CONFIG_SLUB_CPU_PARTIAL is set. Ok that cou.d be fixed by counting the partial slabs when computing /proc/slabinfo output but that would increase the times even more. > Maybe mixing them in a single workaround wasn't the best idea, but what do you > suggest instead? Read select values from /sys/kernel/slab/.... to determine the values you need and avoid reading those that cause latency spikes. Use the number of slabs for example to estimate the number of objects instead of the number of objects which requires scanning through all the individual slab pages.