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 2704CC433EF for ; Fri, 1 Jul 2022 15:04:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 790A16B0071; Fri, 1 Jul 2022 11:04:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 73FB46B0073; Fri, 1 Jul 2022 11:04:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62F926B0074; Fri, 1 Jul 2022 11:04:59 -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 55C7E6B0071 for ; Fri, 1 Jul 2022 11:04:59 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 34CDA2BF for ; Fri, 1 Jul 2022 15:04:59 +0000 (UTC) X-FDA: 79638853518.24.5B8AF3B Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf08.hostedemail.com (Postfix) with ESMTP id BDE1A16006A for ; Fri, 1 Jul 2022 15:04:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656687897; x=1688223897; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=N8o2fHDh/g5iXlzvVYERvl5noxe79p0pRuoz17CCpmc=; b=RI3It3aByh9XjIJ2Lj99z3ZKbi/9eRELyQrLAoY232FSf70V3LePU8AJ 3tr7QgrSB2cgvY7x01/ZmIiDgDiuYlKkJZUJEJ13/l5oaFNAkbtIuyNwa /R+hesktu394yEaiTqutoQl7fDdc6ABlPm7UPer/bu7aoAQU0/volUjqs xoJ8mWR3r+XMnyouFNqM86lHZ2btEJvW6/nZkCrdZFRC6EmNLlbQNbFbi gXxAWjvHyLtexdDzTLoZ4xzhDaZqw1PgVIxaU0T8TDcMsRAzmskdjejL6 WEJPIyt25X+K4g8c6dWymh8KZMCkNKJRn17gavRtj4EsfFJRjZOJHjZoH w==; X-IronPort-AV: E=McAfee;i="6400,9594,10394"; a="281434077" X-IronPort-AV: E=Sophos;i="5.92,237,1650956400"; d="scan'208";a="281434077" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2022 08:04:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,237,1650956400"; d="scan'208";a="681429652" Received: from shbuild999.sh.intel.com (HELO localhost) ([10.239.146.138]) by FMSMGA003.fm.intel.com with ESMTP; 01 Jul 2022 08:04:52 -0700 Date: Fri, 1 Jul 2022 23:04:51 +0800 From: Feng Tang To: Christoph Lameter Cc: Andrew Morton , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, dave.hansen@intel.com, Robin Murphy , John Garry Subject: Re: [PATCH v1] mm/slub: enable debugging memory wasting of kmalloc Message-ID: <20220701150451.GA62281@shbuild999.sh.intel.com> References: <20220701135954.45045-1-feng.tang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=RI3It3aB; spf=none (imf08.hostedemail.com: domain of feng.tang@intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=feng.tang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656687898; 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=dZoNsElLwlLpyHbesiwqLEB+P8GUWv10IBDqu7zG9NU=; b=JijCo7C4VDpylkBrnqUhX9rjT8nIy6YpRWxe3MUbbjt6igHt83npbcIsUoW8q+c/BbG7WH CLJSSDXF6Vpjd1kA9TM2xGuWFyfHAUvW1zJaWN+bbG8xvPavk0tOZCwbndrd1SMYzAGyuF ywH0cPoCbEUBBDRL3oJeAz6luhrn4go= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656687898; a=rsa-sha256; cv=none; b=MOz/lxis/NB+PD+r6Gi+n9CP39lzOVjrRaTaPu0GPZ2U6ecs5o29YBWox3W4z+finkfOmH hd86fM4wNr8hpBwV89il5BESfCktJ5RwMqXz6hijg+IpKcFUqpjiiYVwbwo3GRaEXNfLIW Xm9ofva/tjjUmWarkK1b5NgqDC1jPvY= X-Stat-Signature: 7zifk541e5iaf95s9n7g8mxeidxa77w8 X-Rspamd-Queue-Id: BDE1A16006A Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=RI3It3aB; spf=none (imf08.hostedemail.com: domain of feng.tang@intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=feng.tang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam12 X-Rspam-User: X-HE-Tag: 1656687897-387327 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: Hi Christoph, On Fri, Jul 01, 2022 at 04:37:00PM +0200, Christoph Lameter wrote: > On Fri, 1 Jul 2022, Feng Tang wrote: > > > static void *__slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, > > - unsigned long addr, struct kmem_cache_cpu *c) > > + unsigned long addr, struct kmem_cache_cpu *c, unsigned int orig_size) > > { > > It would be good to avoid expanding the basic slab handling functions for > kmalloc. Can we restrict the mods to the kmalloc related functions? Yes, this is the part that concerned me. I tried but haven't figured a way. I started implemting it several month ago, and stuck with several kmalloc APIs in a hacky way like dump_stack() when there is a waste over 1/4 of the object_size of the kmalloc_caches[][]. Then I found one central API which has all the needed info (object_size & orig_size) that we can yell about the waste : static __always_inline void *slab_alloc_node(struct kmem_cache *s, struct list_lru *lru, gfp_t gfpflags, int node, unsigned long addr, size_t orig_size) which I thought could be still hacky, as the existing 'alloc_traces' can't be resued which already has the count/call-stack info. Current solution leverage it at the cost of adding 'orig_size' parameters, but I don't know how to pass the 'waste' info through as track/location is in the lowest level. Thanks, Feng