Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4963627pxb; Tue, 5 Oct 2021 14:20:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyL2PJHFMi4Z+ajvah6n2jJW4Cll9zkAkoa/Bz9gnoWE2Vdlw476GPm71hxSPX1i+cIiDcg X-Received: by 2002:a05:6402:2052:: with SMTP id bc18mr23062897edb.190.1633468858057; Tue, 05 Oct 2021 14:20:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633468858; cv=none; d=google.com; s=arc-20160816; b=n+TEF274X/evzEk3XEwAM2P3+Kp3bb6fQHv7FCjXhr6SasLieX9INn2OCUDbPRGT5s NX/inyCvjdg7iM3aH2oan8QzEC8LnySExyxdg7Z2t+aDv0fSqxM/JigYGTcdqkBzKHnD 6z+9qWmOkrGzuy19jOUJevUys9vIULvTKYcMCy4qgsDLFSKNKzGyZ5qsWTqKLOBl/OMD yQmss3wGMSaa4O4kRF8myLpOp9PPfexZkoNFhepNFxwySA+0AmW+ow8fHRhE4GwuAXTV m/8VeJrlM8Ei96TMYOIdFP0xVydjrMPNbFn9JEYli/uGMOQ5OvGl8jven0XPLR8CdUm3 QA4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=nhJw+eVdwLWID/P8kr8aO9TYdmwZNctYgVNyY2OJLnY=; b=HBvTBP6lLZxU5VKOiGe0yG2Xnb3ckICpkNSy3TDRyArDSMFNXf3Nj69UXuFijpI5tl gC5lplvyV/06+d7Ys3rbEM1PeKtgndadloI3nZDX0O9VeSmx8TEmv0khOXEcu0yHBJzI eYVyNyC8hXUrlFO7mJdo6YRJHRLxYAPpGTjLUX2PzYW+KqLsWH4SKZETnoSaVBe7PI8Q X1/Hl9knoTzuKJhtgdXQlXPLOJIOwsumHAtBLHlbR1/KyRZPABJ5uv6acnXcO2W9NHw7 QkArwo78az80/KwTJfgBKDLV+wg0dFL/q60cipxsuBfPpgWEuZG74ToXLPMviQBuQJU4 gGeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=2G6uyDBi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b11si13207615edm.525.2021.10.05.14.20.34; Tue, 05 Oct 2021 14:20:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=2G6uyDBi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236093AbhJEVUY (ORCPT + 99 others); Tue, 5 Oct 2021 17:20:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:42756 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236042AbhJEVUY (ORCPT ); Tue, 5 Oct 2021 17:20:24 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 1116C61159; Tue, 5 Oct 2021 21:18:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1633468713; bh=Q6enXg4bysVMT9olwJ7KUXyPIz0nbbHdJJJglJELuyg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=2G6uyDBi6sLSKrs+sYErDvwM9fF1TEpnAxLApQBBQQ+ni+IOf/pBvpefh9eBgJjtG xbncFN0EolZcTVSAJGSXLShpdHgEKjtCwp1hIszOByK+bVn6uFSkEKfHWtTOSxdE57 yfYm3iG28bW99wjzCb2jAlmEaY+HXFIO7QOFkg/Q= Date: Tue, 5 Oct 2021 14:18:32 -0700 From: Andrew Morton To: Jens Axboe Cc: LKML , Linux Memory Management List Subject: Re: [PATCH] mm: don't call should_failslab() for !CONFIG_FAILSLAB Message-Id: <20211005141832.d6f3d4e06c4ad7a06cd554dd@linux-foundation.org> In-Reply-To: References: X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 5 Oct 2021 09:31:43 -0600 Jens Axboe wrote: > Allocations can be a very hot path, and this out-of-line function > call is noticeable. > > --- a/include/linux/fault-inject.h > +++ b/include/linux/fault-inject.h > @@ -64,8 +64,8 @@ static inline struct dentry *fault_create_debugfs_attr(const char *name, > > struct kmem_cache; > > -int should_failslab(struct kmem_cache *s, gfp_t gfpflags); > #ifdef CONFIG_FAILSLAB > +int should_failslab(struct kmem_cache *s, gfp_t gfpflags); > extern bool __should_failslab(struct kmem_cache *s, gfp_t gfpflags); > #else > static inline bool __should_failslab(struct kmem_cache *s, gfp_t gfpflags) > diff --git a/mm/slab.h b/mm/slab.h > index 58c01a34e5b8..92fd6fe01877 100644 > --- a/mm/slab.h > +++ b/mm/slab.h > @@ -491,8 +491,10 @@ static inline struct kmem_cache *slab_pre_alloc_hook(struct kmem_cache *s, > > might_alloc(flags); > > +#ifdef CONFIG_FAILSLAB > if (should_failslab(s, flags)) > return NULL; > +#endif Can we avoid the ifdefs here? > > if (!memcg_slab_pre_alloc_hook(s, objcgp, size, flags)) > return NULL; > diff --git a/mm/slab_common.c b/mm/slab_common.c > index ec2bb0beed75..c21bd447f237 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -1323,6 +1323,7 @@ EXPORT_TRACEPOINT_SYMBOL(kmem_cache_alloc_node); > EXPORT_TRACEPOINT_SYMBOL(kfree); > EXPORT_TRACEPOINT_SYMBOL(kmem_cache_free); > > +#ifdef CONFIG_FAILSLAB > int should_failslab(struct kmem_cache *s, gfp_t gfpflags) > { > if (__should_failslab(s, gfpflags)) > @@ -1330,3 +1331,4 @@ int should_failslab(struct kmem_cache *s, gfp_t gfpflags) > return 0; > } > ALLOW_ERROR_INJECTION(should_failslab, ERRNO); > +#endif Like, --- a/include/linux/fault-inject.h~mm-dont-call-should_failslab-for-config_failslab-fix +++ a/include/linux/fault-inject.h @@ -68,6 +68,10 @@ struct kmem_cache; int should_failslab(struct kmem_cache *s, gfp_t gfpflags); extern bool __should_failslab(struct kmem_cache *s, gfp_t gfpflags); #else +static inline int should_failslab(struct kmem_cache *s, gfp_t gfpflags) +{ + return 0; +} static inline bool __should_failslab(struct kmem_cache *s, gfp_t gfpflags) { return false; --- a/mm/slab.h~mm-dont-call-should_failslab-for-config_failslab-fix +++ a/mm/slab.h @@ -491,10 +491,8 @@ static inline struct kmem_cache *slab_pr might_alloc(flags); -#ifdef CONFIG_FAILSLAB if (should_failslab(s, flags)) return NULL; -#endif if (!memcg_slab_pre_alloc_hook(s, objcgp, size, flags)) return NULL; _