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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 502A1C433EF for ; Fri, 1 Jul 2022 11:13:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7B1736B0071; Fri, 1 Jul 2022 07:13:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 73A046B0073; Fri, 1 Jul 2022 07:13:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DA856B0074; Fri, 1 Jul 2022 07:13:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 495B96B0071 for ; Fri, 1 Jul 2022 07:13:29 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id EE67D606D8 for ; Fri, 1 Jul 2022 11:13:28 +0000 (UTC) X-FDA: 79638270096.15.0807BBE Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf22.hostedemail.com (Postfix) with ESMTP id 22E02C0009 for ; Fri, 1 Jul 2022 11:13:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656674008; x=1688210008; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=vlK/qQ4NX1QkT7AEWx80zOij+hlHTc4NLtDoQtrx+IQ=; b=CE4qhamM+fPizync6AzR+DTPsUTxSLqPosiKS5xMnFjaEnFbtofK6PVV 3/pr+xNWAomPbYRbnSAzLkuI9tl/J6l90SWhbLShZVhipOiRWjo9mnbfW 2iOE0zX992bs+n9fdNzN5f3/SzsH5DwBOmA2l3gnEO2OymEsktCsxeh+1 G6UqPfRKwKlfC33MHvNIKezMCEAa9l3/LzWtSXIF6hUUz+0t1+oXQE14U 5gJJ+YBKDBzn4EfvPN76G2KmKt7ybpVAe88JWi0oUJ0p4vel0J/usO3jg Vx/TxSwIQdqrCoJN4Y8oDFQkZGMMYmfM7OEx2QcSZVEuOyO/Bpquca975 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10394"; a="283360956" X-IronPort-AV: E=Sophos;i="5.92,236,1650956400"; d="scan'208";a="283360956" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2022 04:13:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,236,1650956400"; d="scan'208";a="694478207" Received: from shbuild999.sh.intel.com (HELO localhost) ([10.239.146.138]) by fmsmga002.fm.intel.com with ESMTP; 01 Jul 2022 04:13:23 -0700 Date: Fri, 1 Jul 2022 19:13:22 +0800 From: Feng Tang To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, dave.hansen@intel.com Subject: Re: [RFC PATCH] mm/slub: enable debugging memory wasting of kmalloc Message-ID: <20220701111322.GC14806@shbuild999.sh.intel.com> References: <20220630014715.73330-1-feng.tang@intel.com> <20220701022330.GA14806@shbuild999.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=CE4qhamM; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of feng.tang@intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=feng.tang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656674008; a=rsa-sha256; cv=none; b=7ya8tIM1w38WBA+9NyH+okjs5J/a+8vAe6EE4tjlQ1vQSQAQVuSl4csUyXNiP6V4ltBdQb PH46DHu7puGpkJwC7gV6vbU8iNjE7Ak2tofZaSL8PS3J4+QoRv/RxTjLcc5+iOi3nHVY/p hutbkWsEa9hK+CfDByQ2sjr7pEpjGno= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656674008; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+SMWNvUm4lfD3x3vvaVjPsQZBD9J1UhZCbXrN9r0F9Y=; b=kUKeEom2yX7L3TVqi+s3/6+tO3soKs2STZ1Pf+R9IU+7RjWb5/tk/G2iMUgO2qO2qwoHJk D6wngr2DxzfdGwzMGftGU6PrV4Une/IqX4zHxpNYifDM4HjiDPK9UqldnM/1hTufnYkffK Yb5cYclZ8gypzuvdDaSheG2yEo2PLmg= X-Rspam-User: Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=CE4qhamM; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of feng.tang@intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=feng.tang@intel.com X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 22E02C0009 X-Stat-Signature: 4goffbd3759698qfhnpfs88e8n1xkhw7 X-HE-Tag: 1656674007-434314 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 Fri, Jul 01, 2022 at 06:29:20PM +0900, Hyeonggon Yoo wrote: > On Fri, Jul 01, 2022 at 10:23:30AM +0800, Feng Tang wrote: [snip] > > > > > And then it has overhead of 'waste' field for every non-kmalloc objects > > > because track is saved per object. Also the field is not used at free. > > > (Maybe that would be okay as it's only for debugging, just noting.) > > > > Yes, the field itself is a 'waste' for non-kmalloc objects :) I do > > have another patch to add an option for this > > > > +config SLUB_DEBUG_KMALLOC_WASTE > > + bool "Enable kmalloc memory waste debug" > > + depends on SLUB_DEBUG && DEBUG_FS > > ... > > > > And didn't post it due to the same debugging thought as you. And I can > > add it back if it's really necessary. > > Let's see how others think :) > I'm okay with current patch. Okay. > > > > mm/slub.c | 45 ++++++++++++++++++++++++++++++--------------- > > > > 1 file changed, 30 insertions(+), 15 deletions(-) [snip] > > > > > > > > l->min_pid = track->pid; > > > > l->max_pid = track->pid; > > > > l->handle = handle; > > > > + l->waste = track->waste; > > > > > > I think this may be fooled when there are different wastes values > > > from same caller (i.e. when a kmalloc_track_caller() is used.) > > > > Yes, with the patch, we found quite some cases that the same caller > > requests different sizes. > > > > > because the array is sorted by caller address, but not sorted by waste. > > > > In the patch we have in add_location(): > > > > + if ((track->addr == caddr) && (handle == chandle) && > > + (track->waste == l->waste)) { > > > > Do you mean the following is missed? > > > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -5176,6 +5176,8 @@ static int add_location(struct loc_track *t, struct kmem_cache *s, > > end = pos; > > else if (track->addr == caddr && handle < chandle) > > end = pos; > > + else if (track->addr == caddr && handle == chandle && track->waste < l->waste) > > + end = pos; > > else > > start = pos; > > > > Yes. Exactly. :) Great, will add it in the next version. Thanks for cathing the errors! - Feng > Thanks, > Hyeonggon