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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 E997FC433E0 for ; Fri, 5 Feb 2021 05:17:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4B8ED64FA1 for ; Fri, 5 Feb 2021 05:17:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4B8ED64FA1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9312B6B0005; Fri, 5 Feb 2021 00:17:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E1886B006C; Fri, 5 Feb 2021 00:17:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F7366B006E; Fri, 5 Feb 2021 00:17:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id 69E806B0005 for ; Fri, 5 Feb 2021 00:17:31 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 252E68249980 for ; Fri, 5 Feb 2021 05:17:31 +0000 (UTC) X-FDA: 77783056302.05.pen10_480c0a7275e2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 0C9A9180364F9 for ; Fri, 5 Feb 2021 05:17:31 +0000 (UTC) X-HE-Tag: pen10_480c0a7275e2 X-Filterd-Recvd-Size: 7109 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Fri, 5 Feb 2021 05:17:30 +0000 (UTC) Received: by mail-pg1-f173.google.com with SMTP id z21so3740482pgj.4 for ; Thu, 04 Feb 2021 21:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=O4cRtZruXboHwdwpsrWR0FgPvU0D3io6KdJXESFf9ao=; b=ZJgt47b89QUQlQpNCk2RzHQADY4sdnAmKJ8jK3iomTBS3kuVnET2qJ6TYJeTas0uQJ N0VKrsuo+G8G0p/2boVtfJfg3WK3+LDUux+tXVl+kqApyjiKQW3bL98+eOloGeRPPxck fOLu0QXckPuYgiY63CcKCU8bppXngLh0YJMFJzcWN6XboFp8cuku9yqi64aViGN4pphN VqqaW1wGpXpfoqTDLx0cqdIm9/og7/djeduxtCDG+URYROaS7lTVA5QqflqhW7e3yEvX 1L6xToHizavx21g27FDOAuwMWUrFEZaQE1GbrQxTDo/lI22mtH/33BeysNCLX1dOt5gf /6Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=O4cRtZruXboHwdwpsrWR0FgPvU0D3io6KdJXESFf9ao=; b=ctYMo2zVgcS+hg3dWC5if/RNYdaYe3+wHa6uk7qiUOU72FfcxID+vFSj31+b918fP5 3hUB7t7bCORSLOfuPQF3IruwEVCX9PSBZANEU0wAsflhyJ/bx6TJA3a3CoO44nCUki2L 03ANjzyKLnZ7nkPVgw5RBCse2jFRpt/3BWqJ3r+652HPKo529KDEh1iVaWYWIsJHunRJ iLfxO4fb0vqgFzOOtv3uttsda7SUsSBnO4pO21HaB8j0B4b/7T5iT6yD/89cSL50AEkr gOwrB+nSCtQTqugFHXB0GhAY5ZD0WjmJNQ24jD6ZCwGLhrTGEKE2W/rkXl0y5+Xbv5Xh RyKA== X-Gm-Message-State: AOAM532nYpssIpXqIVZUJ19DoTlZkbiLWdQjd5YCz6IT/jAyJdEqPlCR ATpngAD6TYtNrRTKrrKjrVk= X-Google-Smtp-Source: ABdhPJwD0qHX0hn2zLkvYd5rTaz7KYjrQysriZgmB3LZpcD7MhILeJTe+jTIlkjKVWAnr5Ixl2cTTw== X-Received: by 2002:a65:6152:: with SMTP id o18mr2668294pgv.392.1612502249646; Thu, 04 Feb 2021 21:17:29 -0800 (PST) Received: from google.com ([2620:15c:211:201:598:57c0:5d30:3614]) by smtp.gmail.com with ESMTPSA id v3sm7158907pff.217.2021.02.04.21.17.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Feb 2021 21:17:28 -0800 (PST) Date: Thu, 4 Feb 2021 21:17:26 -0800 From: Minchan Kim To: John Hubbard Cc: Andrew Morton , gregkh@linuxfoundation.org, surenb@google.com, joaodias@google.com, LKML , linux-mm Subject: Re: [PATCH] mm: cma: support sysfs Message-ID: References: <20210203155001.4121868-1-minchan@kernel.org> <7e7c01a7-27fe-00a3-f67f-8bcf9ef3eae9@nvidia.com> <87d7ec1f-d892-0491-a2de-3d0feecca647@nvidia.com> <71c4ce84-8be7-49e2-90bd-348762b320b4@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71c4ce84-8be7-49e2-90bd-348762b320b4@nvidia.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Feb 04, 2021 at 06:52:01PM -0800, John Hubbard wrote: > On 2/4/21 5:44 PM, Minchan Kim wrote: > > On Thu, Feb 04, 2021 at 04:24:20PM -0800, John Hubbard wrote: > > > On 2/4/21 4:12 PM, Minchan Kim wrote: > > > ... > > > > > > 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? > > > > > > > > > > Yes, except that it raises more questions: > > > > > > 1) Isn't this just standard allocation failure? Don't you already have a way > > > to track that? > > > > > > Presumably, having the source code, you can easily deduce that a bluetooth > > > allocation failure goes directly to a CMA allocation failure, right? > > Still wondering about this... It would work if we have full source code and stack are not complicated for every usecases. Having said, having a good central place automatically popped up is also beneficial for not to add similar statistics for each call sites. Why do we have too many item in slab sysfs instead of creating each call site inventing on each own? > > > > > > > Anyway, even though the above is still a little murky, I expect you're right > > > that it's good to have *some* indication, somewhere about CMA behavior... > > > > > > Thinking about this some more, I wonder if this is really /proc/vmstat sort > > > of data that we're talking about. It seems to fit right in there, yes? > > > > Thing is CMA instance are multiple, cma-A, cma-B, cma-C and each of CMA > > heap has own specific scenario. /proc/vmstat could be bloated a lot > > while CMA instance will be increased. > > > > Yes, that would not fit in /proc/vmstat...assuming that you really require > knowing--at this point--which CMA heap is involved. And that's worth poking > at. If you get an overall indication in vmstat that CMA is having trouble, > then maybe that's all you need to start digging further. I agree it could save to decide whether I should go digging further but anyway, I need to go though each of instance once it happens. In that, what I need is per-CMA statistics, not global. I am happy to implement it but I'd like to say it's not my case. > > It's actually easier to monitor one or two simpler items than it is to monitor > a larger number of complicated items. And I get the impression that this is > sort of a top-level, production software indicator. Let me clarify one more time. What I'd like to get ultimately is per-CMA statistics instead of global vmstat for the usecase at this moment. Global vmstat could help the decision whether I should go deeper but it ends up needing per-CMA statistics. And I'd like to keep them in sysfs, not debugfs since it should be stable as a telemetric. What points do you disagree in this view?