Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1594214pxb;
        Thu, 4 Feb 2021 17:59:47 -0800 (PST)
X-Google-Smtp-Source: ABdhPJxUfqK0/5EBAMSl5k3SLTsjOaMSJW0XhTB7cGheUQ29LUDbhRAJyVTwSy2tIjxi66UAyEHU
X-Received: by 2002:a17:906:b752:: with SMTP id fx18mr1894017ejb.17.1612490387323;
        Thu, 04 Feb 2021 17:59:47 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1612490387; cv=none;
        d=google.com; s=arc-20160816;
        b=pfdk1Mz9k/LW08xc4BHv2VGkRUezO9tyxaEULn3G4YiFbceguBoez/g13BGBGpOaQZ
         WHPU/ziH3W0Qlb750Qim0VL3jeVhfupMFRk25oiOTQv3XMSnlMoIIK5285wy4DU4TVCn
         p/k0+KRF1OxGw7V0djHEi6IjAUlfUr01ibcVaPg+mTji+qtjn557s6D9EeaI5zW9mxP2
         iNCr2W7MGUrJmT2J5XzTHeKnQ1DhhajHDj8dztb0TGhkEP4mNWf6E9L0rCLssKNPCw6T
         U0KdoA7B369woxDHSNNi8sHnzHrNoFdMkDWcxkry0+ZwcO5FcnzVJhepuH5TPI8i/8BQ
         ULyQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-id:precedence:dkim-signature:content-transfer-encoding
         :content-language:in-reply-to:mime-version:user-agent:date
         :message-id:from:references:cc:to:subject;
        bh=1kcjylQrdkg3Sq5H+JinBAhi/j6dIB7tX+xGXHh1grk=;
        b=tmkmP/ruFz3Yots7gX9Czg7oTrLdAnBcd2nCeg4Omsx02kLSoMfgH/oGyK993/f+En
         RtVqXQZ3NOdssEibsePHZ4Dz6fTLGGOoxhbEPV5xvbXc/6qWav3TVWgCeYiXZ7MOvSD7
         5RdwhT6rh5JUP/DXrKd+uD4gy9EZmJHEKMczTsoMOW6r689G/e0wYas13WOQ/kTljMVQ
         +QujGQ0kiQPCoRgytXf+ieizFhXHrW2VCRP7lVWJg2xKKzfu9FZA/ikd7ZYWZ08nrBO9
         AHNT2GablHurDYm4AgsUTZkyi5qJ0YGgZmPgwiI38adb8yP2vUv7KpLV3Qr1SJJZisKP
         JOzA==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@nvidia.com header.s=n1 header.b=pmDqpChm;
       spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18])
        by mx.google.com with ESMTP id hp6si4038636ejc.532.2021.02.04.17.59.23;
        Thu, 04 Feb 2021 17:59:47 -0800 (PST)
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;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@nvidia.com header.s=n1 header.b=pmDqpChm;
       spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S231829AbhBEA0g (ORCPT <rfc822;lkml.email@gmail.com> + 99 others);
        Thu, 4 Feb 2021 19:26:36 -0500
Received: from hqnvemgate26.nvidia.com ([216.228.121.65]:17909 "EHLO
        hqnvemgate26.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S231728AbhBEA0c (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 4 Feb 2021 19:26:32 -0500
Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate26.nvidia.com (using TLS: TLSv1.2, AES256-SHA)
        id <B601c90900000>; Thu, 04 Feb 2021 16:25:52 -0800
Received: from [10.2.60.31] (172.20.145.6) by HQMAIL107.nvidia.com
 (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 5 Feb
 2021 00:25:51 +0000
Subject: Re: [PATCH] mm: cma: support sysfs
To:     Suren Baghdasaryan <surenb@google.com>
CC:     Minchan Kim <minchan@kernel.org>,
        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>
References: <20210203155001.4121868-1-minchan@kernel.org>
 <7e7c01a7-27fe-00a3-f67f-8bcf9ef3eae9@nvidia.com>
 <YBxT9XFE6QAQ4T9N@google.com>
 <cda5547b-0c78-756b-bd0c-f3e534d04bff@nvidia.com>
 <CAJuCfpG_J_XkaK=1z2oHkTpq7Pw1qvZLKuYrs7aG5b9yVwvEag@mail.gmail.com>
 <CAJuCfpFAsM86cKbBrhZx0WPFH5HGCYW4gK_EPtDU=gnhkiDSPw@mail.gmail.com>
From:   John Hubbard <jhubbard@nvidia.com>
Message-ID: <9900858e-4d9b-5111-e695-fd2bb7463af9@nvidia.com>
Date:   Thu, 4 Feb 2021 16:25:51 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:85.0) Gecko/20100101
 Thunderbird/85.0
MIME-Version: 1.0
In-Reply-To: <CAJuCfpFAsM86cKbBrhZx0WPFH5HGCYW4gK_EPtDU=gnhkiDSPw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.20.145.6]
X-ClientProxiedBy: HQMAIL101.nvidia.com (172.20.187.10) To
 HQMAIL107.nvidia.com (172.20.187.13)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
        t=1612484752; bh=1kcjylQrdkg3Sq5H+JinBAhi/j6dIB7tX+xGXHh1grk=;
        h=Subject:To:CC:References:From:Message-ID:Date:User-Agent:
         MIME-Version:In-Reply-To:Content-Type:Content-Language:
         Content-Transfer-Encoding:X-Originating-IP:X-ClientProxiedBy;
        b=pmDqpChmd3D6ub12ZuJGl5eyDx87uPRPh3KZJvYJdj0pXWvEFoYbXB/YX1g0GCBbD
         Y+ZeLRH92bVTHrYJ945E6f9/oSGGc2EUoypJwlEAs5kSz4/Bpw4oEUgAsyv8i5xzCV
         /PFwqOtM6wb2fT6fwLd8nQz/IxeuvKKoSxRSkgDdQdN6gzigZ+Q1GixI5lLCY8atQP
         YTHpWO5Dz+WxH1mLcFZ54l2scTtEEssftD+TpZPpd6KRM7MIXJ2Nit3w7fEVdCtGcf
         O3oUx72CLj38Q3BPMht2EwEakvxZF7U/VUY/J+TFAApBDLgm2GFqRrelsthgr6+c5C
         9Fd8Ie4ohkpDA==
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2/4/21 3:45 PM, Suren Baghdasaryan wrote:
...
>>>>> 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.
>>
>> IMHO it would be very useful to see whether there are multiple
>> small-order allocation failures or a few large-order ones, especially
>> for CMA where large allocations are not unusual. For that I believe
>> both alloc_pages_attempt and alloc_pages_fail would be required.
> 
> Sorry, I meant to say "both cma_alloc_fail and alloc_pages_fail would
> be required".

So if you want to know that, the existing items are still a little too indirect
to really get it right. You can only know the average allocation size, by
dividing. Instead, we should provide the allocation size, for each count.

The limited interface makes this a little awkward, but using zones/ranges could
work: "for this range of allocation sizes, there were the following stats". Or,
some other technique that I haven't thought of (maybe two items per file?) would
be better.

On the other hand, there's an argument for keeping this minimal and simple. That
would probably lead us to putting in a couple of items into /proc/vmstat, as I
just mentioned in my other response, and calling it good.


thanks,
-- 
John Hubbard
NVIDIA