From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05BA1C433E0 for ; Wed, 13 Jan 2021 18:12:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 376FB23435 for ; Wed, 13 Jan 2021 18:12:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 376FB23435 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sipsolutions.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A227F8D0085; Wed, 13 Jan 2021 13:12:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D35F8D006A; Wed, 13 Jan 2021 13:12:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C1F28D0085; Wed, 13 Jan 2021 13:12:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0110.hostedemail.com [216.40.44.110]) by kanga.kvack.org (Postfix) with ESMTP id 76BE68D006A for ; Wed, 13 Jan 2021 13:12:16 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 343C71EE6 for ; Wed, 13 Jan 2021 18:12:16 +0000 (UTC) X-FDA: 77701546272.02.kiss44_420cff327520 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id 14EA010097AA1 for ; Wed, 13 Jan 2021 18:12:16 +0000 (UTC) X-HE-Tag: kiss44_420cff327520 X-Filterd-Recvd-Size: 2847 Received: from sipsolutions.net (s3.sipsolutions.net [144.76.43.62]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Wed, 13 Jan 2021 18:12:15 +0000 (UTC) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94) (envelope-from ) id 1kzkcu-005sJl-BD; Wed, 13 Jan 2021 19:12:12 +0100 Message-ID: <0f2b134140bc7a8d4a2619a26e1ca87339b220bd.camel@sipsolutions.net> Subject: Re: [PATCH] mm/slub: disable user tracing for kmemleak caches From: Johannes Berg To: Vlastimil Babka , linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Andrew Morton , Catalin Marinas , Christoph Lameter , David Rientjes , Joonsoo Kim , Pekka Enberg Date: Wed, 13 Jan 2021 19:11:55 +0100 In-Reply-To: <1db7c986-25c4-884e-4fbf-9af348bdff6f@suse.cz> References: <20210113170931.929f808099d2.I117b6764e725b3192318bbcf4269b13b709539ae@changeid> <1db7c986-25c4-884e-4fbf-9af348bdff6f@suse.cz> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 2021-01-13 at 17:59 +0100, Vlastimil Babka wrote: > On 1/13/21 5:09 PM, Johannes Berg wrote: > > From: Johannes Berg > > > > If kmemleak is enabled, it uses a kmem cache for its own objects. > > These objects are used to hold information kmemleak uses, including > > a stack trace. If slub_debug is also turned on, each of them has > > *another* stack trace, so the overhead adds up, and on my tests (on > > ARCH=um, admittedly) 2/3rds of the allocations end up being doing > > the stack tracing. > > > > Turn off SLAB_STORE_USER if SLAB_NOLEAKTRACE was given, to avoid > > storing the essentially same data twice. > > > > Signed-off-by: Johannes Berg > > How about stripping away SLAB_STORE_USER only if it's added from the global > slub_debug variable? In case somebody lists one of the kmemleak caches > explicitly in "slub_debug=..." instead of just booting with "slub_debug", we > should honor that. Good point, that makes a lot of sense. TBH, I mostly sent this to see if anyone would think it acceptable. I've now disabled slub debugging completely for the kmemleak caches by command line, and as expected that improves things further. I'm _hoping_ of course that kmemleak itself doesn't contain egregious bugs, but seems like a fair bet for now :) So what do you/people think? Should we disable this? Disable all? Subject to the above constraint, either way. Thanks, johannes