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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS 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 6614CC433E0 for ; Wed, 3 Mar 2021 23:16:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0296064E5F for ; Wed, 3 Mar 2021 23:16:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0296064E5F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 77F0A6B0005; Wed, 3 Mar 2021 18:16:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 73E946B0006; Wed, 3 Mar 2021 18:16:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F6BF6B0007; Wed, 3 Mar 2021 18:16:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0212.hostedemail.com [216.40.44.212]) by kanga.kvack.org (Postfix) with ESMTP id 3822B6B0005 for ; Wed, 3 Mar 2021 18:16:32 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id F0B0581F3 for ; Wed, 3 Mar 2021 23:16:31 +0000 (UTC) X-FDA: 77880124182.01.03CD390 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf28.hostedemail.com (Postfix) with ESMTP id 3C2FD20053C5 for ; Wed, 3 Mar 2021 23:16:30 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 9D01A64EEF; Wed, 3 Mar 2021 22:44:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1614811490; bh=2rtpPwzLJHVHIJnLXsKsmJg32BkCVjuDiTmHOHM5K7k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=vBNagQ9lTfWPruGCNNpnKngmPSpHpbBdsY6OHavrWAHrdGZcdo1YlOiSZJ8r+bqZs KQWi/SuQ/y/4yBAUAuau3/EbKod66NclsVLGFZ+7iCshfF4KavbJ3gHRH2j3OVKaA2 gWDTXrsgBhzNEbGxMBncnOzqEvaUpcfihlOPWuE0= Date: Wed, 3 Mar 2021 14:44:49 -0800 From: Andrew Morton To: Minchan Kim Cc: linux-mm , LKML , joaodias@google.com, willy@infradead.org, surenb@google.com, Greg Kroah-Hartman , John Hubbard Subject: Re: [PATCH v3] mm: cma: support sysfs Message-Id: <20210303144449.aa69518bfbaec9c71f799dc7@linux-foundation.org> In-Reply-To: <20210303205053.2906924-1-minchan@kernel.org> References: <20210303205053.2906924-1-minchan@kernel.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: rmjy8dksz94qh5sxgddyfs8iw53jjsco X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3C2FD20053C5 Received-SPF: none (linux-foundation.org>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614813390-328836 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, 3 Mar 2021 12:50:53 -0800 Minchan Kim wrote: > Since CMA is getting used more widely, it's more important to > keep monitoring CMA statistics for system health since it's > directly related to user experience. > > This patch introduces sysfs statistics for CMA, in order to provide > some basic monitoring of the CMA allocator. > > * the number of CMA page allocation attempts > * the number of CMA page allocation failures > > These two values allow the user to calcuate the allocation > failure rate for each CMA area. > > e.g.) > /sys/kernel/mm/cma/WIFI/cma_alloc_pages_[attempts|fails] > /sys/kernel/mm/cma/SENSOR/cma_alloc_pages_[attempts|fails] > /sys/kernel/mm/cma/BLUETOOTH/cma_alloc_pages_[attempts|fails] > > ... > > --- a/mm/cma.h > +++ b/mm/cma.h > @@ -3,6 +3,14 @@ > #define __MM_CMA_H__ > > #include > +#include > + > +struct cma_stat { > + spinlock_t lock; > + unsigned long pages_attempts; /* the number of CMA page allocation attempts */ > + unsigned long pages_fails; /* the number of CMA page allocation failures */ > + struct kobject kobj; > +}; > > struct cma { > unsigned long base_pfn; > @@ -16,6 +24,9 @@ struct cma { > struct debugfs_u32_array dfs_bitmap; > #endif > char name[CMA_MAX_NAME]; > +#ifdef CONFIG_CMA_SYSFS > + struct cma_stat *stat; > +#endif > }; Why aren't the stat fields simply placed directly into struct cma_stat? > ... > > +static int __init cma_sysfs_init(void) > +{ > + int i = 0; > + struct cma *cma; > + > + cma_kobj = kobject_create_and_add("cma", mm_kobj); > + if (!cma_kobj) { > + pr_err("failed to create cma kobject\n"); > + return -ENOMEM; > + } > + > + cma_stats = kzalloc(array_size(sizeof(struct cma_stat), > + cma_area_count), GFP_KERNEL); kmalloc_array(..., GFP_KERNEL|__GFP_ZERO); ? > + if (!cma_stats) { > + pr_err("failed to create cma_stats\n"); Probably unneeded - the ENOMEM stack backtrace will point straight here. > + goto out; > + } > + > + do { > + cma = &cma_areas[i]; > + cma->stat = &cma_stats[i]; > + spin_lock_init(&cma->stat->lock); > + if (kobject_init_and_add(&cma->stat->kobj, &cma_ktype, > + cma_kobj, "%s", cma->name)) { > + kobject_put(&cma->stat->kobj); > + goto out; > + } > + } while (++i < cma_area_count); > + > + return 0; > +out: > + while (--i >= 0) { > + cma = &cma_areas[i]; > + kobject_put(&cma->stat->kobj); > + } > + > + kfree(cma_stats); > + kobject_put(cma_kobj); > + > + return -ENOMEM; > +} > +subsys_initcall(cma_sysfs_init);