Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1613301pxb; Thu, 4 Feb 2021 18:36:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJw2B3gaZD+pCMF/rPv+tCpPPUfs/LhUlt17Rf5HYg4PUWEtzOj0R4Fk+atSN+Aol7MKKJhv X-Received: by 2002:a50:e0c1:: with SMTP id j1mr1433112edl.253.1612492616220; Thu, 04 Feb 2021 18:36:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612492616; cv=none; d=google.com; s=arc-20160816; b=Edm0ZfyO0TJBFT8wK9RTTbPbVVr7sdQPkTog8tBCWayO6efWTDZ7/xXGEUemxMCB+Y cHcf9grU/H03UebgVhS3hsu3jbG5seQvOMk7Z1eb4sUzIHsfQUXYYLEUVcNL68ayNu33 zqF6Ny/Dt83Zfvlcyst8ObhTIQbaECRefA0+N3OZteNV66Higg2a5gygj3PJW7y3ziVd x4T1okCAXCS3xwDTKMO4ZfPXSvMN4ixT9/otOaQSBxreoFhShk9uSd3ebl3NuS8sPxcV PQ4KlZKM728rOeBN9U2nWppHp4ebJ0sL/X5qb6xzERXy3xIB2WbmDCa5SOEN1qzXJOvx fF8A== 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:references:cc:to:from:subject; bh=NTqy7B8P6hSTGH18361tq0v8m1sHBP+QMYN9FgAqBkg=; b=i1W3tr70GBLzJEFLA/a8lY6zFYnM0DhYgdInhpAOo68ZoQN93CNUxRFV4tRCOTpBH7 MtaP1w+WZNRqcLYDftOvWC/XpEFq0ZiK54WzggDDedmNIYJeA4F5z2jV6nBAyjy8xr11 U7NyZpiB0NvLuuKeOK23ySyS/7KX1sexcPUiaEx+9DzQv/NKKXfoMelZNlTIqtAnQa+n t/ZNvkCN+PK/7CNnXPyGNG2AtMG2coCyxGDXFx+2nmKVXFz+aBvmx2uPSA6a6LtBIC0a JLtuJIA5AAD7W8fTbTvhAEsr62DvnavELlYoQPF/naZXfxCe+SnDZWt3HDjERO2vx6BK ESOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=KoHnZouS; 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: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j26si1839161eds.297.2021.02.04.18.36.08; Thu, 04 Feb 2021 18:36:56 -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=KoHnZouS; 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 S232018AbhBEAe7 (ORCPT + 99 others); Thu, 4 Feb 2021 19:34:59 -0500 Received: from hqnvemgate26.nvidia.com ([216.228.121.65]:18558 "EHLO hqnvemgate26.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231909AbhBEAe6 (ORCPT ); Thu, 4 Feb 2021 19:34:58 -0500 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:34:18 -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:34:18 +0000 Subject: Re: [PATCH] mm: cma: support sysfs From: John Hubbard 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>

<9900858e-4d9b-5111-e695-fd2bb7463af9@nvidia.com> Message-ID: <96bc11de-fe47-c7d3-6e61-5a5a5b6d2f4c@nvidia.com> Date: Thu, 4 Feb 2021 16:34:17 -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: <9900858e-4d9b-5111-e695-fd2bb7463af9@nvidia.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=1612485258; bh=NTqy7B8P6hSTGH18361tq0v8m1sHBP+QMYN9FgAqBkg=; h=Subject:From:To:CC:References:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:X-Originating-IP:X-ClientProxiedBy; b=KoHnZouStLSRj6n3WdCjFTPGAaGHoQ/9TazFgT3+17/wNco0bavtfsDy+pqQTzz14 ki1nfYyKD9XNO3ASPu8A/+4X+S7BpMbsGuIKzu02etqMQ38zgK3OzqoOyFJa77qtYy j4eM30a/YM0Avv0mGol1sd78NTxjjnDsWvLF8eLKJUUtRgG5EKfXVGvwklOnLj/kCW imZQkufYuOPOxagKlV4rS/++5XlQ29vyfsRN0y2yHorS0SYMNeCrdoLmB7Wjc2T7eb PDPVW1Q/bxKiig8f4607bAi5ACfOyarLhKGU8AHE/vyqZXQH1RWSKppWGDcBLAEa5H aHRJUArUec96w== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/4/21 4:25 PM, John Hubbard wrote: > 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. ...and remember: if we keep it nice and minimal and clean, we can put it into /proc/vmstat and monitor it. And then if a problem shows up, the more complex and advanced debugging data can go into debugfs's CMA area. And you're all set. If Android made up some policy not to use debugfs, then: a) that probably won't prevent engineers from using it anyway, for advanced debugging, and b) If (a) somehow falls short, then we need to talk about what Android's plans are to fill the need. And "fill up sysfs with debugfs items, possibly duplicating some of them, and generally making an unecessary mess, to compensate for not using debugfs" is not my first choice. :) thanks, -- John Hubbard NVIDIA