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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 2963AC433E0 for ; Thu, 14 Jan 2021 11:13:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 88EF823A3B for ; Thu, 14 Jan 2021 11:13:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 88EF823A3B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0C4748D00D7; Thu, 14 Jan 2021 06:13:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 075638D008E; Thu, 14 Jan 2021 06:13:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ECCFF8D00D7; Thu, 14 Jan 2021 06:13:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id D46708D008E for ; Thu, 14 Jan 2021 06:13:11 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 99C19181AEF32 for ; Thu, 14 Jan 2021 11:13:11 +0000 (UTC) X-FDA: 77704118982.14.crowd01_600f88527526 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 7E25D18229835 for ; Thu, 14 Jan 2021 11:13:11 +0000 (UTC) X-HE-Tag: crowd01_600f88527526 X-Filterd-Recvd-Size: 2425 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Thu, 14 Jan 2021 11:13:10 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id C8C4E238A1; Thu, 14 Jan 2021 11:13:08 +0000 (UTC) Date: Thu, 14 Jan 2021 11:13:06 +0000 From: Catalin Marinas To: Johannes Berg Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Vlastimil Babka , Johannes Berg Subject: Re: [PATCH v2] mm/slub: disable user tracing for kmemleak caches by default Message-ID: <20210114111305.GA16561@gaia> References: <20210113215114.d94efa13ba30.I117b6764e725b3192318bbcf4269b13b709539ae@changeid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210113215114.d94efa13ba30.I117b6764e725b3192318bbcf4269b13b709539ae@changeid> User-Agent: Mutt/1.10.1 (2018-07-13) 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, Jan 13, 2021 at 09:51:14PM +0100, 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 I think that's the simplest. Acked-by: Catalin Marinas > Perhaps instead it should go the other way around, and kmemleak > could even use/access the stack trace that's already in there ... > But I don't really care too much, I can just turn off slub debug > for the kmemleak caches via the command line anyway :-) This stack trace doesn't seem to be accessible in a unified way across the sl*b allocators. Given that kmemleak already needs to track this information for other objects (vmalloc, certain page allocations), it's probably more hassle to handle it differently for slab objects (I don't say it's impossible, just not sure it's worth). -- Catalin