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:   Fri, 5 Feb 2021 14:47:18 -0800
From:   Minchan Kim <minchan@kernel.org>
To:     John Hubbard <jhubbard@nvidia.com>
Cc:     Suren Baghdasaryan <surenb@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        John Dias <joaodias@google.com>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: cma: support sysfs
Message-ID: <YB3K9rx7E9qMf6Is@google.com>
References: <71c4ce84-8be7-49e2-90bd-348762b320b4@nvidia.com>
 <YBzU5uUbwa+QIwBQ@google.com>
 <34110c61-9826-4cbe-8cd4-76f5e7612dbd@nvidia.com>
 <YBzkjh5nnuNiGb6Q@google.com>
 <f6e41e39-d60b-764d-0af4-8e6977663821@nvidia.com>
 <YB1vIrgI9S/5CDxL@google.com>
 <269689b7-3b6d-55dc-9044-fbf2984089ab@nvidia.com>
 <YB24YXMJOjwokDb5@google.com>
 <CAJuCfpEaQqgsyGtzRvovpuLOELR0iRNvNF0rnih1bq0HQCTuww@mail.gmail.com>
 <cbd30192-6f9f-845c-6b1c-e21ed737781d@nvidia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cbd30192-6f9f-845c-6b1c-e21ed737781d@nvidia.com>
Precedence: bulk

On Fri, Feb 05, 2021 at 01:58:06PM -0800, John Hubbard wrote:
> On 2/5/21 1:52 PM, Suren Baghdasaryan wrote:
> > > > > I takes your suggestion something like this.
> > > > > 
> > > > > [alloc_range] could be order or range by interval
> > > > > 
> > > > > /sys/kernel/mm/cma/cma-A/[alloc_range]/success
> > > > > /sys/kernel/mm/cma/cma-A/[alloc_range]/fail
> > > > > ..
> > > > > ..
> > > > > /sys/kernel/mm/cma/cma-Z/[alloc_range]/success
> > > > > /sys/kernel/mm/cma/cma-Z/[alloc_range]/fail
> > 
> > The interface above seems to me the most useful actually, if by
> > [alloc_range] you mean the different allocation orders. This would
> > cover Minchan's per-CMA failure tracking and would also allow us to
> > understand what kind of allocations are failing and therefore if the
> > problem is caused by pinning/fragmentation or by over-utilization.
> > 
> 
> I agree. That seems about right, now that we've established that
> cma areas are a must-have.

Okay, now we agreed the dirction right now so let me do that in next
version. If you don't see it's reasonable, let me know.

* I will drop the number of CMA *page* allocation attemtps/failures to
make simple start
* I will keep CMA allocation attemtps/failures
* They will be under /sys/kernel/mm/cma/cma-XX/success,fail
* It will turn on CONFIG_CMA && CONFIG_SYSFS

Orthognal work(diffrent patchset)

* adding global CMA alloc/fail into vmstat
* adding alloc_range success/failure under CONFIG_CMA_ALLOC_TRACKING
  whatever configuration or just by default if everyone agree

Thanks.