Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 4 Sep 2022 07:38:17 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
        Vishal Verma <vishal.l.verma@intel.com>,
        Dan Williams <dan.j.williams@intel.com>,
        "Dave Jiang" <dave.jiang@intel.com>,
        Ira Weiny <ira.weiny@intel.com>
CC:     <linux-kernel@vger.kernel.org>, <kernel-janitors@vger.kernel.org>,
        Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
        <nvdimm@lists.linux.dev>
Subject: RE: [PATCH] nvdimm: Avoid wasting some memory.
Message-ID: <6314b859df5e2_2202c6294f5@dwillia2-xfh.jf.intel.com.notmuch>
References: <8355cb2b720f8cd0f1315b06d70b541ba38add30.1662299370.git.christophe.jaillet@wanadoo.fr>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8355cb2b720f8cd0f1315b06d70b541ba38add30.1662299370.git.christophe.jaillet@wanadoo.fr>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?YmDewM41pOCB9HE9mn9jikTDoMtJhNshSuHzQZYv/BmyO7JzAx6uboe6iNRa?=
 =?us-ascii?Q?pg469NDkFHLpZd3Ay8Qbm1jjWqgyvFrm0I7Z++qGwnKNHEruZ1F90ODzl/W7?=
 =?us-ascii?Q?37f5XJkhE3/tqZLd6tuFr3YLStR47vKBEgzhixRt9OXRwoY3iSkOnGvAmulI?=
 =?us-ascii?Q?YJ6qQeHYCorAy44hgSKsly4vuEEbuqafPLiZL728os3WX3xXR9vKeQfNahrl?=
 =?us-ascii?Q?ulHU4o+FZNnL2EjqNWiY9Mm4oV0LpBLZ7waNlEzdtaO5eQXcsw7+BxaPEIPJ?=
 =?us-ascii?Q?Ic+M9oZw9NHIuALQBIGXWFE1fZDo0DVqZTEI8EaRaAJvGkbBLFv4g+hJCicA?=
 =?us-ascii?Q?foUcinqEAML3FszbtiKb8O02TOefCafCH949HhJ4dmDH5n4nmlSwaLqOb/pc?=
 =?us-ascii?Q?netTbFcZXXdTbaII5MQvGW+leCwXQL2oHJja3pulbf9T3PJdXMYYO9df3ZxS?=
 =?us-ascii?Q?qEz8idou75/mWylA7Nxg63LqIsLc1hvuHmBsmcZFSeHzfdgDlFziZYOAGFY/?=
 =?us-ascii?Q?igKLWWaRq4RhZ07v6xvEZNHY5pHfS2JRcbTFSxZ8mc8aKXZ9DnKUYnbeoQXi?=
 =?us-ascii?Q?eCs2zwwwVBAJp9w72DZ+4AEY6761ji3l6Gp8RAixsnFxFG45nbe47UUOjYAm?=
 =?us-ascii?Q?gqa/8Bz5WlYBCr4exVMi8eUoUP4JXVVXq9XtbdpPEfQsMtS80PVJhGFv992Y?=
 =?us-ascii?Q?6C7WBVEquPYjO5n9vOr/jbkVCZF+ps533i45Ysfztrgb/4jfyKbl5puNlw/x?=
 =?us-ascii?Q?eCzdPTgSvVpEEEfSA05/LbKXYSVTvYJ/P2T+FUV5f5KxOU1IE9jd1xUWQC/8?=
 =?us-ascii?Q?ohujQ+6TygitxZTtjMKXjBU6E2x2SmgfelzGyh7y8s2m8em1KhQ5hP+lSKre?=
 =?us-ascii?Q?jB0lVvqNP1iODSII/prMyQ0lXMN9iSzjt2OZts8LfW+RZRFanSGAHg+MWC9f?=
 =?us-ascii?Q?pWEQBLUAXFbGN/cZghxMoyMSdocq9zANtlBwlpDsHkm63/BzoT872exQmpzR?=
 =?us-ascii?Q?7LuoVS7LYxEiZ+z2deiCfUCvdbYb38aicnbrujn6ttcIMyUrLl8YToz4DyVc?=
 =?us-ascii?Q?ZIaR3qiNDIKcDv4saJ4ChglwtB6F2O42Cku177AmWWAZFGFmhtBKv7NTwF5V?=
 =?us-ascii?Q?fFIZcGkyzNG6gQHyCX7Bvy+tKl7Te6BPv/Gvb9tsMy2/lfaUehAwxjKsPfHP?=
 =?us-ascii?Q?hw6XBMSTGrPPBcKSCA0wFRhBRQSXo44MZRWfowbkitYxXJKnnaUIDVYuJ8Lg?=
 =?us-ascii?Q?AfedXV3E/YELnsFqtN4k8G/C+zYlhWapT3KygrZ9Dbft5BMeWWdJVRSN5O/5?=
 =?us-ascii?Q?BpJJMIm+KiWrX4L9dvARsHoQgbipyX7t2HvV9j/aczLTkh6DUSgh4rN5sjsg?=
 =?us-ascii?Q?oLmZGrkXNv8XcUzTOtvrxDolDDmQ0YY0iIRDDCzULrzfFHf/Sml1OAy3K5b7?=
 =?us-ascii?Q?BsoIj6MYuYQCrZr6+hUMbvvKo3pIaaBOObUsZPcDASSMzxtl39MDqHs3zQXH?=
 =?us-ascii?Q?gJus0QacZnRznirao9dsZNKYcJyzkP0q+wuNvZICATVpLv1UuTUWRwJ+/85Y?=
 =?us-ascii?Q?tOXOy00gBo4pGtqaLu2P0YxJQRs3UU7BGU98Rt49+Z0WHb/Pr/1vEoY3OSwN?=
 =?us-ascii?Q?6w=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 179ab892-64bc-44d0-044c-08da8e831cb7
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1101MB2126.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2022 14:38:20.2306
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Pbj69Gf2+QOBphhCxhnQ6A1/oXFkCZyNUJGP+mW+jgLDg/mBseGuyVi5TxJ7179RrnX7/7URxG6ImvbmlxkmAQCQnqo+5fxBys7QfWa6Cuc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1305
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Christophe JAILLET wrote:
> sizeof(struct btt_sb) is 4096.
> 
> When using devm_kzalloc(), there is a small memory overhead and, on most
> systems, this leads to 40 bytes of extra memory allocation.
> So 5036 bytes are expected to be allocated.
> 
> The memory allocator works with fixed size hunks of memory. In this case,
> it will require 8192 bytes of memory because more than 4096 bytes are
> required.
> 
> In order to avoid wasting 4ko of memory, just use kzalloc() and add a
> devm action to free it when needed.
> 
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
>  drivers/nvdimm/btt_devs.c | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
> index fabbb31f2c35..7b79fb0b0338 100644
> --- a/drivers/nvdimm/btt_devs.c
> +++ b/drivers/nvdimm/btt_devs.c
> @@ -332,6 +332,11 @@ static int __nd_btt_probe(struct nd_btt *nd_btt,
>  	return 0;
>  }
>  
> +void nd_btt_free(void *data)
> +{
> +	kfree(data);
> +}
> +
>  int nd_btt_probe(struct device *dev, struct nd_namespace_common *ndns)
>  {
>  	int rc;
> @@ -356,7 +361,17 @@ int nd_btt_probe(struct device *dev, struct nd_namespace_common *ndns)
>  	nvdimm_bus_unlock(&ndns->dev);
>  	if (!btt_dev)
>  		return -ENOMEM;
> -	btt_sb = devm_kzalloc(dev, sizeof(*btt_sb), GFP_KERNEL);
> +
> +	/*
> +	 * 'struct btt_sb' is 4096. Using devm_kzalloc() would waste 4 ko of
> +	 * memory because, because of a small memory over head, 8192 bytes
> +	 * would be allocated. So keep this kzalloc()+devm_add_action_or_reset()
> +	 */
> +	btt_sb = kzalloc(sizeof(*btt_sb), GFP_KERNEL);
> +	rc = devm_add_action_or_reset(dev, nd_btt_free, btt_sb);
> +	if (rc)
> +		return rc;

Thanks for the analysis and the patch. However, shouldn't this be
something that is addressed internal to devm_kzalloc() rather than
open-coded at every potential call site?