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=-8.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_PATCH,MAILING_LIST_MULTI,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 73E21C433DB for ; Thu, 4 Mar 2021 01:38:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EB94465031 for ; Thu, 4 Mar 2021 01:38:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB94465031 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 64EB36B0005; Wed, 3 Mar 2021 20:38:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 625186B0006; Wed, 3 Mar 2021 20:38:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C5BE6B0007; Wed, 3 Mar 2021 20:38:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0222.hostedemail.com [216.40.44.222]) by kanga.kvack.org (Postfix) with ESMTP id 2F8CF6B0005 for ; Wed, 3 Mar 2021 20:38:17 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D9B1E4DD6 for ; Thu, 4 Mar 2021 01:38:16 +0000 (UTC) X-FDA: 77880481392.19.AE6EC0E Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by imf05.hostedemail.com (Postfix) with ESMTP id D155DE0011E0 for ; Thu, 4 Mar 2021 01:38:15 +0000 (UTC) Received: by mail-pg1-f182.google.com with SMTP id e6so17751947pgk.5 for ; Wed, 03 Mar 2021 17:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5RzlHn4xFRh1Zx79ORyn6MfrsS+lNJ1vPReW80eTB3E=; b=UzzJplrA+FoaUIs6vVFqHpyo+BUwyG1DYilJI6kodVPoMKbAuSZUkPY0cxTEppgWBN mzKtQZ3FsnmBKJU2uw+t50HaT27+0nkKaaNSAJ7sNDlt7IBDhsAJ34AAxvdV3khyD8DT pJWXqYN+MPQ1+8kFodjaSjg1ZRoGH4b4EWOxeDEFDBWKzRerXEM74HSznqJYv6exjd6Y POmfygtbtp5ULsCvaS9Ahawb4Qwm0MI2KOfos69+M1Xm0RDIKh2RxRPdiIgm1fYf5ykS IDpOHNWnFqbQd6uhA/wmsegEeLRYyIRyOTt7bj/A3twy4DDXI9SblgWtZFn+QUzL9KkC eObw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=5RzlHn4xFRh1Zx79ORyn6MfrsS+lNJ1vPReW80eTB3E=; b=GHh2gn4WCQrDlFjiAxOQ1GDMe8Rv7KNwukEwPt72iOHCZIIgXhvgj0UEMqvSaifdYB 2P7aVOUXwbBWcmXtTRhfJKrq2XztlvN+vFpv4CtWwFQ3o5Og162kwaZUnatjZHDbr/6V nAHivNi51qfm4Gy6sgXDRgyIHjX+5sPJHpfum54vGRkSUGbn50YKQgl3IjGlSQGCq4VP 9akCUqdJ4g2eLau0sbQvW5MYFHeqtYQ3vrYOqYRnnGH5rhvRQVA8RZ6iDmqulEEktmP0 D2cXMIL8BmWTUmbFmZ4J31fwfX+phJ7eGfjcdX8TkIt6e6TH+GqJYsZRD82jc1wYoYHD Rj8A== X-Gm-Message-State: AOAM532RP5zZ5YnSCedRWSWau1GBSs3XHBPAaKnAne4buuV3aGSARRST iPgovsOwwfmKvAPz4geumjU= X-Google-Smtp-Source: ABdhPJyR3HXwyIFHBX5fFAFE7aa3y92ete2pVPs9zFiKehki51VmjR9w7IYuXCTJ5sVabeX5vxqRbA== X-Received: by 2002:aa7:8d92:0:b029:1ee:75d1:c87 with SMTP id i18-20020aa78d920000b02901ee75d10c87mr1547429pfr.9.1614821895386; Wed, 03 Mar 2021 17:38:15 -0800 (PST) Received: from google.com ([2620:15c:211:201:c87:c34:99dc:ba23]) by smtp.gmail.com with ESMTPSA id m9sm7562093pjl.4.2021.03.03.17.38.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Mar 2021 17:38:14 -0800 (PST) Date: Wed, 3 Mar 2021 17:38:12 -0800 From: Minchan Kim To: Andrew Morton 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: References: <20210303205053.2906924-1-minchan@kernel.org> <20210303144449.aa69518bfbaec9c71f799dc7@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210303144449.aa69518bfbaec9c71f799dc7@linux-foundation.org> X-Stat-Signature: 89ega8d7bma47uka3tr4pmxqa639m43g X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D155DE0011E0 Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf05; identity=mailfrom; envelope-from=""; helo=mail-pg1-f182.google.com; client-ip=209.85.215.182 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614821895-530953 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, Mar 03, 2021 at 02:44:49PM -0800, Andrew Morton wrote: > 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? It have a related long discussion. https://lore.kernel.org/linux-mm/YCIoHBGELFWAyfMi@kroah.com/ https://lore.kernel.org/linux-mm/YCLLKDEQ4NYqb5Y5@kroah.com/ TLDR - Greg really want to see kobject stuff working as dynamic property. > > > ... > > > > +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); Yub. > > ? > > > + if (!cma_stats) { > > + pr_err("failed to create cma_stats\n"); > > Probably unneeded - the ENOMEM stack backtrace will point straight here. I failed to find the point you mentioned to print backtrace. Where code do you mean to dump the backtrace?