Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp141073imm; Tue, 19 Jun 2018 17:51:03 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKqT5QoJcRVyTJrnOifNfVqRfqmshtEYAw3S1yKwB29aYMqJ++UC0yK9nJ9E2gVhsdvZWFV X-Received: by 2002:a17:902:103:: with SMTP id 3-v6mr21267177plb.229.1529455862999; Tue, 19 Jun 2018 17:51:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529455862; cv=none; d=google.com; s=arc-20160816; b=uOwonIvMnQYjqZdtbTy9uWP/the9Ms+epaHdxBNlJxasGizacCsfKhuj/QtCMUBno2 4T6j/EvoT+7WOqiOjxPQhoXbZdbTtyXNpfMY0Z3Rg4+qYj247bpjyERShTJ83DRYPBNJ C60qb7vfTgXaWPYYlqfvlxPw2+auyYh6y1AV4/1fKUnk3K6GYdoTi9xmRnrDk+dLNelv uVe0BmfEbu2hvUEu7UlIebmY6bS0Dc27ri15ElZMPzaGB3PJZZezSHVOJUJlniCwwS+S XYvgDhm/MsF/IAPAiK4HbQOl6vsnxDzFoSA91remyrjjon6wQnhHYdMHTWw1GeCN8vdM BWew== 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:dkim-signature :arc-authentication-results; bh=JpFWqVr5vWw+tyS7McnlpT+MWLRu44AXJHuMei2pYI0=; b=GGPogZ463+SXDPbgFpDCYibsVbJeoR11ETU0lTxPMra2z6QgTk2kjH9Gu1NycYRN+R H81Bt+WQsoqYxIZu8w7H5DdcTZo70unUGwNMtWLBgbvuCYviym+Qwa+C/o6SDDGG2+XQ 8sGzqt1PhmgbIGXohtlPkm3xYuZqoAx26IQZf062RRJRw1schymvvLJ4DsrtZlvbNjgH e6v0fKRasZE5PA/93mUYQVVmyMi6d5ezCxPJUW5MlpAMynS0pkLdltZ0m3AI/CTyl3vR AjnVnK026Clc9EWVQAd9R4RE2vEY/8yBzS04yFSFtJEOmCNsrtTaMGyxh3MO9Vf5AohZ dFlg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=itD1mQ3w; 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 y7-v6si821772pgp.157.2018.06.19.17.50.48; Tue, 19 Jun 2018 17:51:02 -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=itD1mQ3w; 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 S1753685AbeFTAtt (ORCPT + 99 others); Tue, 19 Jun 2018 20:49:49 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:46843 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752707AbeFTAtq (ORCPT ); Tue, 19 Jun 2018 20:49:46 -0400 Received: by mail-pl0-f68.google.com with SMTP id 30-v6so746563pld.13 for ; Tue, 19 Jun 2018 17:49:46 -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=JpFWqVr5vWw+tyS7McnlpT+MWLRu44AXJHuMei2pYI0=; b=itD1mQ3wB/IgDD9LwqgB/GZagqzk+aMcuQc/02T3x4sse1KRXJnd98sIlqPdK5bQz1 t/6/Bv6AE6BHEFAbl5j9N7AJbrrR3SwZv2ZjnHlQWQAfRW7Dbvr+I/buRhoGBy2cRqbw fW0CZylUtDC+VQQVYzxmUzU5fwyW37VA9xkJQ68z9JkKVOP4IHDRrKa6d+CzMNzlYoe3 ZrBcDMBnfEK2JgzLhBwkqFJF13La5IgzNkK36j+qMQlC2Hln6ZAfwEL68VWNj1vFsLtE 1/8ukQjGj0B/wmEpb+UzrvRfrS5WBGq7y3I1aRykc0QCI2bggHlZ2c1Q4w+y0GBf8jZK CQjw== 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=JpFWqVr5vWw+tyS7McnlpT+MWLRu44AXJHuMei2pYI0=; b=qx+gEdl/e77Wpl0gVwlX2l7mCMdrRvpkHjJ9au/dPHMNXKA9jGrfXiBSRbjJB/sIFi 6u0Y7rTlZMGB9/MeVdqVk1/3+Cz7GuFFhuDgM6cE47B2UPSF0o5hZy6/1JuJt3qr8pxV GbD1UPmDAkloOB102Z3KrvyTYsmPS3ngYUclULEkizRwTGj1TipjQbsr2vFq3Zd2yKzQ qiOXL2T3RHxMp2QxeOwHvgAG63CwhJVbQf66/hDE+fEftWdK+mxenWDWXRhzHURir4uH ED+xTj2KRXbaf+aALeBJ76IpZQyoFzbTqMeXqgIkCcfOehoFl2mc2Bgsq2Mv0I7DXgtz biuA== X-Gm-Message-State: APt69E1ONQwdQyzKQ36V1M1UpLhfzxd5XZ+XgCARvYBXg6bOHk3kwLAP WudUKFjMCTfojfKqDE3uNRdjDbeGZrw= X-Received: by 2002:a17:902:2884:: with SMTP id f4-v6mr21243564plb.204.1529455785612; Tue, 19 Jun 2018 17:49:45 -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 n76-v6sm1219764pfg.98.2018.06.19.17.49.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Jun 2018 17:49:44 -0700 (PDT) Date: Tue, 19 Jun 2018 17:49:44 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Shakeel Butt cc: "Jason A . Donenfeld" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christoph Lameter , Pekka Enberg , Joonsoo Kim , Andrew Morton , stable@vger.kernel.org Subject: Re: [PATCH] slub: fix __kmem_cache_empty for !CONFIG_SLUB_DEBUG In-Reply-To: <20180619213352.71740-1-shakeelb@google.com> Message-ID: References: <20180619213352.71740-1-shakeelb@google.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 Tue, 19 Jun 2018, Shakeel Butt wrote: > diff --git a/mm/slub.c b/mm/slub.c > index a3b8467c14af..731c02b371ae 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -3673,9 +3673,23 @@ static void free_partial(struct kmem_cache *s, struct kmem_cache_node *n) > > bool __kmem_cache_empty(struct kmem_cache *s) > { > - int node; > + int cpu, node; Nit: wouldn't cpu be unused if CONFIG_SLUB_DEBUG is disabled? > struct kmem_cache_node *n; > > + /* > + * slabs_node will always be 0 for !CONFIG_SLUB_DEBUG. So, manually > + * check slabs for all cpus. > + */ > + if (!IS_ENABLED(CONFIG_SLUB_DEBUG)) { > + for_each_online_cpu(cpu) { > + struct kmem_cache_cpu *c; > + > + c = per_cpu_ptr(s->cpu_slab, cpu); > + if (c->page || slub_percpu_partial(c)) > + return false; > + } > + } > + > for_each_kmem_cache_node(s, node, n) > if (n->nr_partial || slabs_node(s, node)) > return false; Wouldn't it just be better to allow {inc,dec}_slabs_node() to adjust the nr_slabs counter instead of doing the per-cpu iteration on every shutdown?