Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <77045024-cf1d-472a-9cf5-5b492a4a0e02@quicinc.com>
Date:   Fri, 11 Aug 2023 12:24:29 +0530
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] cma: introduce CMA_ALLOC_DEBUG config
Content-Language: en-US
To:     Andrew Morton <akpm@linux-foundation.org>
CC:     <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
        <quic_pkondeti@quicinc.com>, <quic_charante@quicinc.com>
References: <20230809131640.18791-1-quic_bibekkum@quicinc.com>
 <20230810095451.cada824810441ecc955e2b2e@linux-foundation.org>
From:   Bibek Kumar Patro <quic_bibekkum@quicinc.com>
In-Reply-To: <20230810095451.cada824810441ecc955e2b2e@linux-foundation.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 8/10/2023 10:24 PM, Andrew Morton wrote:
> On Wed, 9 Aug 2023 18:46:40 +0530 Bibek Kumar Patro <quic_bibekkum@quicinc.com> wrote:
> 
>> Currently enabling CONFIG_CMA_DEBUG enables DEBUG preprocessor macro.
>> If DEBUG is defined, it's equivalent to a printk with KERN_DEBUG loglevel
>> flooding the dmesg buffer with pr_debug prints from mm/cma driver and from
>> included files as well. This results in excessive amount of CMA logging and
>> also might distract the debug teams with unrelated KERN_DEBUG prints.One of
>> the ways engineers currently tackle this problem is by passing loglevel=N
>> though commandline to suppress KERN_DEBUG messages. This approach can
>> sometimes become tiresome due to its repetitive nature.
>> This patch proposes an alternative approach by introducing a simple new
>> config CONFIG_CMA_ALLOC_DEBUG which only shows the cma bit allocation
>> status in case of cma failure and do not enable DEBUG preprocessor macro
>> from CONFIG_CMA_DEBUG avoiding excessive CMA logging from pr_debug.
>> Engineers and tech teams seeking only for bitmap status in case of cma
>> failure can use this simple config instead of worrying about changing
>> the loglevel or trying other similar workarounds.
> 
> Would it be better to control this at runtime?  With a /proc or /sys tunable?

Currently it's being controlled at runtime by changing the 
/proc/sys/kernel/printk tunable or through loglevel value in cmdline but 
issue faced by engineers in both these approach is these tunable value 
would reset every time on reboot and won't retain the set value. So 
these approaches are being used as workarounds only as of now.
Also another issue with the earlier CMA_DEBUG config is the text code 
size might increase (It might be minuscule sometimes but will happen) 
due to all pr_debug in the code.