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=-7.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 D5E18C433DB for ; Fri, 5 Feb 2021 00:25:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4D17E64FAE for ; Fri, 5 Feb 2021 00:25:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4D17E64FAE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D40AD6B0006; Thu, 4 Feb 2021 19:25:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CF0F56B006C; Thu, 4 Feb 2021 19:25:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C07176B006E; Thu, 4 Feb 2021 19:25:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0103.hostedemail.com [216.40.44.103]) by kanga.kvack.org (Postfix) with ESMTP id AB87C6B0006 for ; Thu, 4 Feb 2021 19:25:54 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 75621180AD807 for ; Fri, 5 Feb 2021 00:25:54 +0000 (UTC) X-FDA: 77782321428.17.rail62_0514f6a275e0 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 5694E180D0180 for ; Fri, 5 Feb 2021 00:25:54 +0000 (UTC) X-HE-Tag: rail62_0514f6a275e0 X-Filterd-Recvd-Size: 4210 Received: from hqnvemgate26.nvidia.com (hqnvemgate26.nvidia.com [216.228.121.65]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Fri, 5 Feb 2021 00:25:53 +0000 (UTC) Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate26.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; 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 CC: Minchan Kim , Andrew Morton , Greg Kroah-Hartman , John Dias , LKML , linux-mm References: <20210203155001.4121868-1-minchan@kernel.org> <7e7c01a7-27fe-00a3-f67f-8bcf9ef3eae9@nvidia.com>

From: John Hubbard 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: 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== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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