Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4244069pxj; Tue, 25 May 2021 03:41:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxVXtO2cDJa98j6jlJ/bmuSSh3DrbzDJBekJvE7xVM1Xk9uGRZM9eRzD0kL5lRp4SQuyVlJ X-Received: by 2002:a05:6402:35cc:: with SMTP id z12mr30591168edc.154.1621939297386; Tue, 25 May 2021 03:41:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621939297; cv=none; d=google.com; s=arc-20160816; b=PHcrZpLNQX7Pb5/PPCUZn9PM24EQ/RGu5PSmLfiR7K/eBzs3Rp/cSbIeJNpdgHLqQM iAGYzVRbxuBqcRn4SorD8HEYUGyxRzUpm8UeDKdTi2i2eqDBBE2zgUfYhT5pBm7rBp9J zsyfZnKfcGQu6jSdUdRHaS/NkwOlbm5+ei2x4o7ARI7y+p8Qb1Vq13taN9Yqth0Hs0Qj L7M146x6ao6FX1qAzzwxkl7pWd85R0SmlA1B6uQDFLoDX/xNeZhvPBaqtpaGeKY1kdli nK1lMmGA+u+u3i4A+kKgxpW4Pi5NSVU8tIozQNDx6Sj79rRGpDxnwYfi7oK0an10M9Y+ r1sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=2f0/MfCGrcLGFAD7G6Of5oa+94u/JCD0vyrnaB6GQzU=; b=zcf+jyVydjKjDzSNRGJ6hF7pVX1lVlODKbzJ1CFFCJA654jJxvilRDZv82CURV6H1X yryXRLF8eVFy2xbK3qfCDSQqLi+Jwe6sIAn3H3PF90i1XMhzCP0eIXgMAMFPBv08zE0B HAvZvrKIYCmlLaR3u+LEzP47niFlUEnv1X4R8oTEptjegu6nNJsyEeTAfpucspWdQsNX FZkS8FBkvOwK4PHSZ8OfKcIhdBxkaGRBhcBmJ0gGWF1DJYZdg3Jv7uVS5QueEKotY0vz 2sHpwu284faL1OF1GPZ5SDB1LF3fxQ5qjLm5QaxnvKN3Smm3ylnSkPVyALQ5RM7xILPa Xi6w== ARC-Authentication-Results: i=1; mx.google.com; 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 w1si15021064edt.513.2021.05.25.03.41.15; Tue, 25 May 2021 03:41:37 -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; 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 S229736AbhEYKTS (ORCPT + 99 others); Tue, 25 May 2021 06:19:18 -0400 Received: from outbound-smtp24.blacknight.com ([81.17.249.192]:50724 "EHLO outbound-smtp24.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229597AbhEYKTP (ORCPT ); Tue, 25 May 2021 06:19:15 -0400 Received: from mail.blacknight.com (pemlinmail01.blacknight.ie [81.17.254.10]) by outbound-smtp24.blacknight.com (Postfix) with ESMTPS id AE9E1C0BED for ; Tue, 25 May 2021 11:17:44 +0100 (IST) Received: (qmail 1239 invoked from network); 25 May 2021 10:17:44 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.23.168]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 25 May 2021 10:17:44 -0000 Date: Tue, 25 May 2021 11:17:42 +0100 From: Mel Gorman To: Vlastimil Babka Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christoph Lameter , David Rientjes , Pekka Enberg , Joonsoo Kim , Sebastian Andrzej Siewior , Thomas Gleixner , Jesper Dangaard Brouer , Peter Zijlstra , Jann Horn Subject: Re: [RFC 02/26] mm, slub: allocate private object map for validate_slab_cache() Message-ID: <20210525101742.GK30378@techsingularity.net> References: <20210524233946.20352-1-vbabka@suse.cz> <20210524233946.20352-3-vbabka@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20210524233946.20352-3-vbabka@suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 25, 2021 at 01:39:22AM +0200, Vlastimil Babka wrote: > validate_slab_cache() is called either to handle a sysfs write, or from a > self-test context. In both situations it's straightforward to preallocate a > private object bitmap instead of grabbing the shared static one meant for > critical sections, so let's do that. > > Signed-off-by: Vlastimil Babka > > > > @@ -4685,10 +4685,17 @@ static long validate_slab_cache(struct kmem_cache *s) > int node; > unsigned long count = 0; > struct kmem_cache_node *n; > + unsigned long *obj_map; > + > + obj_map = bitmap_alloc(oo_objects(s->oo), GFP_KERNEL); > + if (!obj_map) > + return -ENOMEM; > Most callers of validate_slab_cache don't care about the return value except when the validate sysfs file is written. Should a simply informational message be displayed for -ENOMEM in case a writer to validate fails and it's not obvious it was because of an allocation failure? It's a fairly minor concern so whether you add a message or not Acked-by: Mel Gorman -- Mel Gorman SUSE Labs