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 E248EEB64D7 for ; Mon, 19 Jun 2023 03:25:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 340E98D0002; Sun, 18 Jun 2023 23:25:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F04A8D0001; Sun, 18 Jun 2023 23:25:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B7E38D0002; Sun, 18 Jun 2023 23:25:41 -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 0967A8D0001 for ; Sun, 18 Jun 2023 23:25:41 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id BB6C712030C for ; Mon, 19 Jun 2023 03:25:40 +0000 (UTC) X-FDA: 80918057640.19.C4D3DFD Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf24.hostedemail.com (Postfix) with ESMTP id EB5B318001A for ; Mon, 19 Jun 2023 03:25:38 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=HxeWxx7P; spf=pass (imf24.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687145139; 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=XEWxz/lAHcb9ZYFwTzi5yFIz0pVTlPeZn6ivja4OCxo=; b=WFAbktJxyLmT54hr6AA/AngvSaRlEpnRcVDsfp/ka63Tap++mM3Ly/W+vIa3bOplWCRsFo oq9JEmcurZseEO09XdbeHlIDl5j82+J2NSM/2tFeirtxi1QvzyIvKSivLeXXZkEZAGHceI l40oTsKcs1Sx10KDMC2Sx1+nLrBNIZ8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687145139; a=rsa-sha256; cv=none; b=MUuc/DC8Zd84ELY360lzr7ojSAGlPbAh/gtnudP10K2uYhqNU6CC/qP0CqfcvtXPA+Fe/F f+GHF/cFT3rO91fPUyhOpOxvTFE5E4NqQCVMD9m44ArUXqm4Vbl0aXLo3FUbWhveMeHgC5 IqRd++0gm14TeyN6d0pTz/f7ovTpSHc= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=HxeWxx7P; spf=pass (imf24.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-1b4f9583404so24168255ad.2 for ; Sun, 18 Jun 2023 20:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687145138; x=1689737138; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=XEWxz/lAHcb9ZYFwTzi5yFIz0pVTlPeZn6ivja4OCxo=; b=HxeWxx7PimRjJ0qPMlFQ4esU+Uaj9dRvYhHmRNfrfEkuwmAE42ZaB7ry1O39WBAoPu o1wiLRFLmCf3n/dqXX8L7f0ueGMhEwSXAF2fegkYhSCwiQzKvRYpQSGB2mELZ9VCR76e 91mrwD6H3O5i5F4zpjP5RWOpcPRFCmJam3kblWmBKHFwBAz9DvBmm/2WZ/wW7EJjnYbC G9/9VTgll53XB/PE8zxMQw2+22VT1NTaSl5AHU9Iv96EG+Wnwer3CS9lGDWZItTj2L/7 LRQbVZLGWFYCr0xbiWMcU1bEb+kaOmY1Ffj84SNxISr4fGmmtEXSyr6S3CdahZpuMx2B uTfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687145138; x=1689737138; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XEWxz/lAHcb9ZYFwTzi5yFIz0pVTlPeZn6ivja4OCxo=; b=B7eLRNkZ6mnsfAkRXfkQxORTqC5WagndMUN450mdQZC4oV7hUgpB4DdoJROBzRlh33 4eva023sFlmJjPuWU9Ru30BebdcebzEIH6mDU0YSjiUtHNKFlJBDjQ7Kn+Ii+Z5JzsMQ vM16RqC5etFFSF7BwhhjbQqA+48gAU0UM4W3u9+IeGldqxt1xB77T4ir9aoMorVYnp6a hhsIrUmfAPkw8oHNS7WhcIMpc7mGH9C3iYuGoyioIARodbeL+atzmkLJcYVVHngyUflQ 3QFnJ0jJ8SamjcFZxXuGc19Xl1U1i7kGPYBQbzSDBPUu9lRKWjDmTw4N6gU8TQLjzh8m v6fQ== X-Gm-Message-State: AC+VfDyKPsybcNTOu1+lMUYkzulKdTG1UxOkhf+JYwSov2UNJChsU8tL Q+zJqrBJY5MfvU4Jta1k2fA= X-Google-Smtp-Source: ACHHUZ6mJR+nEF+nHcmFkWbTtcNtjTyzDNOKPmNb1q31LBorUlP2WDnJMrGcaW82aML9cUJMSV5+vg== X-Received: by 2002:a17:903:2343:b0:1b5:640a:887a with SMTP id c3-20020a170903234300b001b5640a887amr3063209plh.60.1687145137644; Sun, 18 Jun 2023 20:25:37 -0700 (PDT) Received: from fedora ([1.245.179.104]) by smtp.gmail.com with ESMTPSA id 13-20020a170902c20d00b001b53be3d956sm3705332pll.167.2023.06.18.20.25.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Jun 2023 20:25:37 -0700 (PDT) Date: Mon, 19 Jun 2023 12:25:19 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Jay Patel Cc: linux-mm@kvack.org, cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz, aneesh.kumar@linux.ibm.com, tsahu@linux.ibm.com, piyushs@linux.ibm.com, roman.gushchin@linux.dev Subject: Re: [RFC PATCH ] mm/slub: Reducing slub memory wastage Message-ID: References: <20230612085535.275206-1-jaypatel@linux.ibm.com> <51045addfd3ec7804bcc36daed5827bf51095b68.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51045addfd3ec7804bcc36daed5827bf51095b68.camel@linux.ibm.com> X-Stat-Signature: fh3mwndpkd1ise9fupb6ydwic84tndht X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: EB5B318001A X-Rspam-User: X-HE-Tag: 1687145138-260116 X-HE-Meta: U2FsdGVkX1/4LN+OxrjY0Gi25tVqbEVeEg67TIRyZlQ1cEccVWO6kbPdrQlsdYxRWjLB2gcMtTIAqLjP7wa4oyQdU1ENQOzhUMVaWHWaNFmLmAJv/hKnfaGOH+jk3H57nrVRSKv88p4V+R0HsUdgqEAVdFaTXqTY+v/l2ETQEGQE74cpPHKil7a84cLXTYinIUT/cKN4/8x0+TXYFgKD59kEgecSn/vhFrcnYv5JrxRwI2JjOEadpCnAV5rOmlAps3xMtvDI7PFTn4Lo4P+itIr1t86j6xddunIFXq9YkVdsyJlmNVd+FKR1lsP1a/oU+H2PjFD5FsfVb+vdIwzTxQ/AUjP3rkbukdYNpQ7+RTHX2MufZmkaxx9fgRkQBZq8dHv7wyyKl//uBou+Ag53ue6ZhKSyfLhDQAcjJanFYCzrIJudQRMLM3tkP9sO917QQP9IFYdIVJFRJnv4p50BHaZ8UKzdk18ZQcwW74AvTqp13WxKXdjAXBUtagM92yp8kO3a4wfOsT0+3IOCqZRSR3ByJda9UuZUo1ErevGDQUnJtI85ZoB2KM8KlADBmOcdEN5BZQ49eM0UHbkdxxh1UTZIg8rjThEO8Epvq7T6OLhaFgAnFMF1PVlR6q5yAYcUC1o6R80CkebM+bjEMVQrtOcNbpelYqTZ92VTvV50J/sLNc5mzMx28ru1dVrLMyf+qEZLdTds7riJuMKR3I+vKAPw1T6GwqoqoUEWByGWKPEk2uupOGHT6WmduIiuhdauijedmQEzQyGH/snHYbJ5orLovxDjd8xrYxfBBjvCnofevEdXy5VAy1wnFnrf7BWXCl8Kw0vmvY5MRI8bjo9XbPUYZQ+YnkST9Kr3afDHc3c7N1FKSYIB2qldAITMiE08+2BTaCapdj9tdIPNzoBJO6+K/zlTuMk8XwFP/LNqpK0V1QTOBZ88dwCfgWvSFHSc67Cjo1+pE7DvILZuAU0 KCUhVLd9 FuKF6Vqb4cKQ9Y27fvwHZf7wry/tifPx7LjWk4L5KSkH2H/hzrx4IAd1A0pWBWfzEizSaxRE1ohmYgM/FmygvmBizZsFXfovkolckRAJhe+Y83hET5nWHuX4Ht8uVicatPGkfqU7+ZpSgOYsoAQXbU3vrJdLA85hhgrlZxbCPt6g1/PPvRnjQDj75zLMR/GxIhH8belegksh2rDkCkru1VTA8lIj7AZ59oo9lsRP5GDMqz1YSPP+m/7iGipp2dALJgo7brBgpke+Qq+TllzAOW8cuIotyHjk6h1BnjXyzHl59G1FxsLrCNoTUdUkWzwYCnSHtmSTE1ToQog/jF+4j7i49BYruX8SI2A+5ahZ0lQFHSLPreW1fFC5ySQLnHRveyHje8tjLTRqzBHOWBGGh128dQxU7M+A+XTdZ7Pv1PmMJ6YDsZlp6fmTCb59ejHGbjBy3q6QVTiK4lFY= 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 Tue, Jun 13, 2023 at 06:25:48PM +0530, Jay Patel wrote: > > <...snip...> > > > I conducted tests on systems with 160 CPUs and 16 CPUs, using 4K > > > and > > > 64K page sizes. Through these tests, it was observed that the patch > > > successfully reduces the wastage of slab memory without any > > > noticeable > > > performance degradation in the hackbench test report. However, it > > > should > > > be noted that the patch also increases the total number of objects, > > > leading to an overall increase in total slab memory usage. > > > > <...snip...> > > > > Then my question is that, why is this a useful change if total memory > > usage is increased? > > > This patch aimed in reducing memory wastage can potentially lead to an > increase in the slab order for a slab cache. Consequently, this > increase in page order can result in a higher number of objects per > slab, reducing wastage and leading to a more efficient utilization of > memory. if you define utilization as percentage of memory that is being used out of total memory, utilization becomes worse... (based on data you provided) I think 'less memory wastage' is a useful feature only if the total memory usage is reduced so that it could be used for other purposes. I mean, if it consumes more memory on a same workload (in most cases), who would like it? > This enhancement is advantageous since the presence of unused > objects can be leveraged in the future, depending on varying > workloads. At least we need to know when it is leveraged and what kinds of workloads would benefit... Thanks, -- Hyeonggon Yoo Undergraduate | Chungnam National University