Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp992526imm; Fri, 22 Jun 2018 08:35:15 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLD74aGDm02w4Y9m5cQ+pdtdr4U4WVNvVXSjMgrq4P1OZlmDmZVXUVUUUx2bg9YjifWtuiK X-Received: by 2002:a63:8f0d:: with SMTP id n13-v6mr1913254pgd.109.1529681715305; Fri, 22 Jun 2018 08:35:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529681715; cv=none; d=google.com; s=arc-20160816; b=dM6EQ5KZU8xF5RqSN01LYjYH5FGaAGhe6Hh6auUWy+YrdZ42KOF77gmuXlXxnL2ci1 I+wudCGr1WpgOn+CiQ7GdDZymt5scqe78TXdjx/M5H/SJLqVvKf51rLJF0uqo9bvJwtV tKzS/ehbL2tUZlfIb+6U8IMMDOw1WeydM7/X0d7ZA0MijbRmG+kzuahQoEwZhYk1ItZE JaemEkiAzgkpPCXXbQECE/aQsSQ7vpXUCEsxNZJyfQfq6iTC4Z8QcjebiVt/vCXYTaKb nUDu24znLKrjMAdTtrQ1d6YAxusp2AyvRbeG4nTTpe47hv9jsYXMehfcq0VEUVlnQYnn pkkQ== 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 :arc-authentication-results; bh=e2ZpZRMO5Zxl1TQ5jcvOeTPicfb43lcGtkmgOqtPeyk=; b=yegieeExi7fOfiZYbi98J4xrtnb9aqLuB2nQSneoB/DnJ37chRjgIpBTUb4k8yyU36 rDGm/lQ+y9+vsPXkwNb/qkvJ3gfiNw1BjkYJfviaQX+emvzFAEmt9UM4bKyUuisAiDO1 /Um96r0FV6MvGtbUujdx4iTR5IvtqFGvhFKQtXx9+v6RFB/UzRVAfoCEwLnrT4Rd9ufT AIZ7DxLVuiapWYz8wv4045N6epfqa/Nc8YlbR02E7CdpQiXL91jMsERh9006rkG5hbLp Ulz9G34Px2R5sK4ghE9hhsLu/cx7IN0Vk99gEGjyVabu9Yd7F3lIpseo+mj660z+FtPs EFmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=QLTLgBA+; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d33-v6si5545616pla.57.2018.06.22.08.34.55; Fri, 22 Jun 2018 08:35:15 -0700 (PDT) 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; dkim=pass header.i=@google.com header.s=20161025 header.b=QLTLgBA+; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933897AbeFVPdz (ORCPT + 99 others); Fri, 22 Jun 2018 11:33:55 -0400 Received: from mail-wr0-f194.google.com ([209.85.128.194]:46523 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933662AbeFVPdy (ORCPT ); Fri, 22 Jun 2018 11:33:54 -0400 Received: by mail-wr0-f194.google.com with SMTP id l14-v6so2055617wrq.13 for ; Fri, 22 Jun 2018 08:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e2ZpZRMO5Zxl1TQ5jcvOeTPicfb43lcGtkmgOqtPeyk=; b=QLTLgBA+XXIzLTZgQMqfncMO/Gmew4vSKGaYK40/jL8zzmcKHpDbanBZR8YOrRmC2W z2jvWsjUuQIGbrr17rh6+WU1qpSMKDNYw5ZFZWN1GHMGmxj4VJrvxpeTeX5Xd2q5NNPj CNUD6q9hzsjuwCioihJ+Wd73UQ8/qttWXziQnhd1ZelIna/19Ehs12FlSuZHeWGO2nLt eEkNP8tbp0W2HMAZH/7L+9VSmLWtc0UIskLWyPm5cwa/f/06mcjrm2b7u22LzW3QkZh/ k8CvyEEcFvPs7BEuYdUm/JNCqhxsxMmE+2lzUoqJs1rkx4/s2HRdEvt2Gv8ZWv3vhNQw Z5zA== 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=e2ZpZRMO5Zxl1TQ5jcvOeTPicfb43lcGtkmgOqtPeyk=; b=Y4GluCr8RTmNv7vCrsHCP+3G25Jxxt88V7WwNI7EH9dt6pRtgEYafn2Utdpq1NE3sw sQprcEz7FX7DsY3Z1e9EckpiGAaOfZyX2c0Pndhk3D4tBC9MvdIWvZa6LtYPxKmmRcJL f8AXMiOT6xPsuLny7YDvfTgfLhAMkWM7v/PVFyh0K2ZbJKdyGVHFe6NxJvw1iXBRHA/T xSwxRc3AyuTM18SCj3tD+DsTGNYyb1/zllp5GJjM5t6rwKSnt5JnYuA00faHUOcfs1nf Dg1HcrSxxOotq20MSLgGx3eXVe6toGVXr/Kvx01mn+r5RYq9zX/Htc6IgIVhadmpBBF8 gXQw== X-Gm-Message-State: APt69E0lG4tcUeHKnLr9A/E325qjlfY4cEg+xEwGhws3K1qBuFj+l4D+ b1+o64d/SsSMcmRdDx8kMx1FRgVmmeMgz6OFVErqRw== X-Received: by 2002:adf:dd03:: with SMTP id a3-v6mr2144408wrm.2.1529681632401; Fri, 22 Jun 2018 08:33:52 -0700 (PDT) MIME-Version: 1.0 References: <20180620224147.23777-1-shakeelb@google.com> <010001641fe92599-9006a895-d1ea-4881-a63c-f3749ff9b7b3-000000@email.amazonses.com> <20180621150122.GB13063@dhcp22.suse.cz> In-Reply-To: <20180621150122.GB13063@dhcp22.suse.cz> From: Shakeel Butt Date: Fri, 22 Jun 2018 08:33:40 -0700 Message-ID: Subject: Re: [PATCH] slub: track number of slabs irrespective of CONFIG_SLUB_DEBUG To: Michal Hocko Cc: Christoph Lameter , "Jason A . Donenfeld" , David Rientjes , Pekka Enberg , Joonsoo Kim , Andrew Morton , Andrey Ryabinin , Linux MM , LKML , stable@vger.kernel.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 Thu, Jun 21, 2018 at 8:01 AM Michal Hocko wrote: > > On Thu 21-06-18 01:15:30, Cristopher Lameter wrote: > > On Wed, 20 Jun 2018, Shakeel Butt wrote: > > > > > For !CONFIG_SLUB_DEBUG, SLUB does not maintain the number of slabs > > > allocated per node for a kmem_cache. Thus, slabs_node() in > > > __kmem_cache_empty(), __kmem_cache_shrink() and __kmem_cache_destroy() > > > will always return 0 for such config. This is wrong and can cause issues > > > for all users of these functions. > > > > > > CONFIG_SLUB_DEBUG is set by default on almost all builds. The only case > > where CONFIG_SLUB_DEBUG is switched off is when we absolutely need to use > > the minimum amount of memory (embedded or some such thing). > > I thought those would be using SLOB rather than SLUB. > > > > > > The right solution is to make slabs_node() work even for > > > !CONFIG_SLUB_DEBUG. The commit 0f389ec63077 ("slub: No need for per node > > > slab counters if !SLUB_DEBUG") had put the per node slab counter under > > > CONFIG_SLUB_DEBUG because it was only read through sysfs API and the > > > sysfs API was disabled on !CONFIG_SLUB_DEBUG. However the users of the > > > per node slab counter assumed that it will work in the absence of > > > CONFIG_SLUB_DEBUG. So, make the counter work for !CONFIG_SLUB_DEBUG. > > > > Please do not do this. Find a way to avoid these checks. The > > objective of a !CONFIG_SLUB_DEBUG configuration is to not compile in > > debuggin checks etc etc in order to reduce the code/data footprint to the > > minimum necessary while sacrificing debuggability etc etc. > > > > Maybe make it impossible to disable CONFIG_SLUB_DEBUG if CGROUPs are in > > use? > > Why don't we simply remove the config option altogether and make it > enabled effectively. > Christopher, how do you want to proceed? I don't have any strong opinion. I just don't want KASAN users kept broken for SLUB. thanks, Shakeel