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=-13.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 2B190C433E0 for ; Thu, 4 Feb 2021 20:07:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C0ADC60203 for ; Thu, 4 Feb 2021 20:07:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C0ADC60203 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 5D1D46B0006; Thu, 4 Feb 2021 15:07:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 583136B006E; Thu, 4 Feb 2021 15:07:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 472266B0070; Thu, 4 Feb 2021 15:07:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0243.hostedemail.com [216.40.44.243]) by kanga.kvack.org (Postfix) with ESMTP id 30F2E6B0006 for ; Thu, 4 Feb 2021 15:07:22 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D88AF180AD804 for ; Thu, 4 Feb 2021 20:07:21 +0000 (UTC) X-FDA: 77781669882.05.57DB197 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf09.hostedemail.com (Postfix) with ESMTP id EC7D260001AF for ; Thu, 4 Feb 2021 20:07:20 +0000 (UTC) Received: by mail-pl1-f170.google.com with SMTP id b17so2346573plz.6 for ; Thu, 04 Feb 2021 12:07:21 -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=3g2YdFFOBsK1UzWuh7itdWF6Pzv+CzXoJ4Ui6H/0fgA=; b=VAyZpB7r+7xqgOIbs8+IuAKKdVcFH9OlkFXuOky917ADs2skp24/LthVyjdQZX2ayq xXR/3YMo7ZsDaoagNtapW/b1Ibuhk/bpLmuj+s3QR4+qJqbao7Imd9GYxFwaAVUF9CXc lMEL9coVZDJT3Vy5by7LrUvo8HfxZfbXl6qAnajX+5yUxYybs8ecBIG6943/oS1vwUsc /niQoSJNsSDpqd5OVQ0Oc40arCqiXz8wAZo2g1V0Na+aLqHqvVlFFFTZZQSsp4tiAWBO P46vVrZsnSjxghjOG6/XbxEBtioD4OnjB6drxUqwvkqE4KnN7HxitIrxIjYV8GaIe5Vx E0og== 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=3g2YdFFOBsK1UzWuh7itdWF6Pzv+CzXoJ4Ui6H/0fgA=; b=Yj+ym1/g3plZgfW/9JXX3mrDE9TiMydIy86lBKPVZAB1T9ejxxLmg4Igp5WX5NI9/P Duqrlz7Z0GS4Zn2F0FwRi0luWBYr7j3Bjqo3ujIDEPUhiNSKIiLF/va+5i6M6MJR4+7Y NMP0Qer7sl6FwNDpDYbOBhvUbywIaXMVfBRPBcH3fayTUwsGn+WFm59S2fPb9qQdnZZD MbMSCNFblWGXf0i1++Jcp/UAdh6ITS6wNcbmHhstu2vpAIvYzWSpSDnGTAyKW3/X8I3c wv3G8psLkmtRvDCIV7EALTB+CoSJ66Sdf28k1lBZnQ64P6Bp3aZuGPCc7nVpx1iWDGVB t9xw== X-Gm-Message-State: AOAM533A1GJx7eDsLbvL5Da9NyYDLgwd+OQ/+qOBP9UDPpne73eBdvFs O2JI3FNotHa+NjA9rjNNb2M= X-Google-Smtp-Source: ABdhPJx2pDxpy0ANrcj8xHkDPFXK9KldlEknHOtngWb1VJiCkVj1RQmCjG6+zyfoIdwVvObNdk6pAQ== X-Received: by 2002:a17:90b:350b:: with SMTP id ls11mr636974pjb.166.1612469240330; Thu, 04 Feb 2021 12:07:20 -0800 (PST) Received: from google.com ([2620:15c:211:201:598:57c0:5d30:3614]) by smtp.gmail.com with ESMTPSA id f3sm6278088pfe.25.2021.02.04.12.07.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Feb 2021 12:07:19 -0800 (PST) Date: Thu, 4 Feb 2021 12:07:17 -0800 From: Minchan Kim To: John Hubbard Cc: Andrew Morton , gregkh@linuxfoundation.org, surenb@google.com, joaodias@google.com, LKML , linux-mm Subject: Re: [PATCH] mm: cma: support sysfs Message-ID: References: <20210203155001.4121868-1-minchan@kernel.org> <7e7c01a7-27fe-00a3-f67f-8bcf9ef3eae9@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7e7c01a7-27fe-00a3-f67f-8bcf9ef3eae9@nvidia.com> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: EC7D260001AF X-Stat-Signature: 4ft455mxonhrngananotg3h1h1jp75jo Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf09; identity=mailfrom; envelope-from=""; helo=mail-pl1-f170.google.com; client-ip=209.85.214.170 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1612469240-415791 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 Thu, Feb 04, 2021 at 12:50:58AM -0800, John Hubbard wrote: > On 2/3/21 7:50 AM, 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 for the CMA and exposes stats below > > to keep monitor for telemetric in the system. > > > > * the number of CMA allocation attempts > > * the number of CMA allocation failures > > * the number of CMA page allocation attempts > > * the number of CMA page allocation failures > > The desire to report CMA data is understandable, but there are a few > odd things here: > > 1) First of all, this has significant overlap with /sys/kernel/debug/cma > items. I suspect that all of these items could instead go into At this moment, I don't see any overlap with item from cma_debugfs. Could you specify what item you are mentioning? > /sys/kernel/debug/cma, right? Anyway, thing is I need an stable interface for that and need to use it in Android production build, too(Unfortunately, Android deprecated the debugfs https://source.android.com/setup/start/android-11-release#debugfs ) What should be in debugfs and in sysfs? What's the criteria? Some statistic could be considered about debugging aid or telemetric depening on view point and usecase. And here, I want to use it for telemetric, get an stable interface and use it in production build of Android. In this chance, I'd like to get concrete guideline what should be in sysfs and debugfs so that pointing out this thread whenever folks dump their stat into sysfs to avoid waste of time for others in future. :) > > 2) The overall CMA allocation attempts/failures (first two items above) seem > an odd pair of things to track. Maybe that is what was easy to track, but I'd > vote for just omitting them. Then, how to know how often CMA API failed? There are various size allocation request for a CMA so only page allocation stat are not enough to know it. > > > > Signed-off-by: Minchan Kim > > --- > > Documentation/ABI/testing/sysfs-kernel-mm-cma | 39 +++++ > > include/linux/cma.h | 1 + > > mm/Makefile | 1 + > > mm/cma.c | 6 +- > > mm/cma.h | 20 +++ > > mm/cma_sysfs.c | 143 ++++++++++++++++++ > > 6 files changed, 209 insertions(+), 1 deletion(-) > > create mode 100644 Documentation/ABI/testing/sysfs-kernel-mm-cma > > create mode 100644 mm/cma_sysfs.c > > > > diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-cma b/Documentation/ABI/testing/sysfs-kernel-mm-cma > > new file mode 100644 > > index 000000000000..2a43c0aacc39 > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-kernel-mm-cma > > @@ -0,0 +1,39 @@ > > +What: /sys/kernel/mm/cma/ > > +Date: Feb 2021 > > +Contact: Minchan Kim > > +Description: > > + /sys/kernel/mm/cma/ contains a number of subdirectories by > > + cma-heap name. The subdirectory contains a number of files > > + to represent cma allocation statistics. > > Somewhere, maybe here, there should be a mention of the closely related > /sys/kernel/debug/cma files. > > > + > > + There are number of files under > > + /sys/kernel/mm/cma/ directory > > + > > + - cma_alloc_attempt > > + - cma_alloc_fail > > Are these really useful? They a summary of the alloc_pages items, really. > > > + - alloc_pages_attempt > > + - alloc_pages_fail > > This should also have "cma" in the name, really: cma_alloc_pages_*. No problem. > > > + > > +What: /sys/kernel/mm/cma//cma_alloc_attempt > > +Date: Feb 2021 > > +Contact: Minchan Kim > > +Description: > > + the number of cma_alloc API attempted > > + > > +What: /sys/kernel/mm/cma//cma_alloc_fail > > +Date: Feb 2021 > > +Contact: Minchan Kim > > +Description: > > + the number of CMA_alloc API failed > > + > > +What: /sys/kernel/mm/cma//alloc_pages_attempt > > +Date: Feb 2021 > > +Contact: Minchan Kim > > +Description: > > + the number of pages CMA API tried to allocate > > + > > +What: /sys/kernel/mm/cma//alloc_pages_fail > > +Date: Feb 2021 > > +Contact: Minchan Kim > > +Description: > > + the number of pages CMA API failed to allocate > > diff --git a/include/linux/cma.h b/include/linux/cma.h > > index 217999c8a762..71a28a5bb54e 100644 > > --- a/include/linux/cma.h > > +++ b/include/linux/cma.h > > @@ -49,4 +49,5 @@ extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align, > > extern bool cma_release(struct cma *cma, const struct page *pages, unsigned int count); > > extern int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data); > > + > > A single additional blank line seems to be the only change to this file. :) Oops.