Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: Minchan Kim <minchan.kim@gmail.com>
Date:   Thu, 4 Feb 2021 16:12:03 -0800
From:   Minchan Kim <minchan@kernel.org>
To:     John Hubbard <jhubbard@nvidia.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        gregkh@linuxfoundation.org, surenb@google.com, joaodias@google.com,
        LKML <linux-kernel@vger.kernel.org>,
        linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: cma: support sysfs
Message-ID: <YByNU4Q7cc7gYwPh@google.com>
References: <20210203155001.4121868-1-minchan@kernel.org>
 <7e7c01a7-27fe-00a3-f67f-8bcf9ef3eae9@nvidia.com>
 <YBxT9XFE6QAQ4T9N@google.com>
 <cda5547b-0c78-756b-bd0c-f3e534d04bff@nvidia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cda5547b-0c78-756b-bd0c-f3e534d04bff@nvidia.com>
Precedence: bulk

On Thu, Feb 04, 2021 at 03:14:56PM -0800, John Hubbard wrote:
> On 2/4/21 12:07 PM, Minchan Kim wrote:
> > 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?
> 
> Just the fact that there would be two systems under /sys, both of which are
> doing very very similar things: providing information that is intended to
> help diagnose CMA.
> 
> > 
> > > /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
> > )
> 
> That's the closest hint to a "why this is needed" that we've seen yet.
> But it's only a hint.
> 
> > 
> > What should be in debugfs and in sysfs? What's the criteria?
> 
> Well, it's a gray area. "Debugging support" goes into debugfs, and
> "production-level monitoring and control" goes into sysfs, roughly

True.

> speaking. And here you have items that could be classified as either.
> 
> > 
> > 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?
> 
> Why would you even need to know that, *in addition* to knowing specific
> page allocation numbers that failed? Again, there is no real-world motivation
> cited yet, just "this is good data". Need more stories and support here.

Let me give an example.

Let' assume we use memory buffer allocation via CMA for bluetooth
enable of  device.
If user clicks the bluetooth button in the phone but fail to allocate
the memory from CMA, user will still see bluetooth button gray.
User would think his touch was not enough powerful so he try clicking
again and fortunately CMA allocation was successful this time and
they will see bluetooh button enabled and could listen the music.

Here, product team needs to monitor how often CMA alloc failed so
if the failure ratio is steadily increased than the bar,
it means engineers need to go investigation.

Make sense?