* [PATCH v2] cma: introduce CMA_ALLOC_DEBUG config
@ 2023-08-09 13:16 Bibek Kumar Patro
2023-08-09 13:57 ` Bibek Kumar Patro
2023-08-10 16:54 ` Andrew Morton
0 siblings, 2 replies; 7+ messages in thread
From: Bibek Kumar Patro @ 2023-08-09 13:16 UTC (permalink / raw)
To: akpm
Cc: linux-mm, linux-kernel, quic_pkondeti, quic_charante, Bibek Kumar Patro
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.
Signed-off-by: Bibek Kumar Patro <quic_bibekkum@quicinc.com>
---
mm/Kconfig | 11 +++++++++++
mm/cma.c | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index 09130434e30d..ad2a20576a65 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -891,12 +891,23 @@ config CMA
config CMA_DEBUG
bool "CMA debug messages (DEVELOPMENT)"
depends on DEBUG_KERNEL && CMA
+ select CMA_ALLOC_DEBUG
help
Turns on debug messages in CMA. This produces KERN_DEBUG
messages for every CMA call as well as various messages while
processing calls such as dma_alloc_from_contiguous().
This option does not affect warning and error messages.
+config CMA_ALLOC_DEBUG
+ bool "CMA bitmap status upon failure"
+ depends on CMA
+ help
+ Turns on bitmap dump in case of cma failures. This prints
+ current status of CMA bit upon failures and will appear
+ when cma_alloc() return no_warn argument as false and won't
+ flood the dmesg buffer with unrelated KERN_DEBUG prints. No
+ need to explicitly enable this if CMA_DEBUG is enabled.
+
config CMA_DEBUGFS
bool "CMA debugfs interface"
depends on CMA && DEBUG_FS
diff --git a/mm/cma.c b/mm/cma.c
index a4cfe995e11e..0ead392769b3 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -383,7 +383,7 @@ int __init cma_declare_contiguous_nid(phys_addr_t base,
return ret;
}
-#ifdef CONFIG_CMA_DEBUG
+#ifdef CONFIG_CMA_ALLOC_DEBUG
static void cma_debug_show_areas(struct cma *cma)
{
unsigned long next_zero_bit, next_set_bit, nr_zero;
--
2.17.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v2] cma: introduce CMA_ALLOC_DEBUG config
2023-08-09 13:16 [PATCH v2] cma: introduce CMA_ALLOC_DEBUG config Bibek Kumar Patro
@ 2023-08-09 13:57 ` Bibek Kumar Patro
2023-08-10 16:54 ` Andrew Morton
1 sibling, 0 replies; 7+ messages in thread
From: Bibek Kumar Patro @ 2023-08-09 13:57 UTC (permalink / raw)
To: akpm; +Cc: linux-mm, linux-kernel, quic_pkondeti, quic_charante
v2 was added by mistake. It's first submission of the patch. Please
ignore the v2.
regards,
Bibek
On 8/9/2023 6:46 PM, Bibek Kumar Patro 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.
>
> Signed-off-by: Bibek Kumar Patro <quic_bibekkum@quicinc.com>
> ---
> mm/Kconfig | 11 +++++++++++
> mm/cma.c | 2 +-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 09130434e30d..ad2a20576a65 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -891,12 +891,23 @@ config CMA
> config CMA_DEBUG
> bool "CMA debug messages (DEVELOPMENT)"
> depends on DEBUG_KERNEL && CMA
> + select CMA_ALLOC_DEBUG
> help
> Turns on debug messages in CMA. This produces KERN_DEBUG
> messages for every CMA call as well as various messages while
> processing calls such as dma_alloc_from_contiguous().
> This option does not affect warning and error messages.
>
> +config CMA_ALLOC_DEBUG
> + bool "CMA bitmap status upon failure"
> + depends on CMA
> + help
> + Turns on bitmap dump in case of cma failures. This prints
> + current status of CMA bit upon failures and will appear
> + when cma_alloc() return no_warn argument as false and won't
> + flood the dmesg buffer with unrelated KERN_DEBUG prints. No
> + need to explicitly enable this if CMA_DEBUG is enabled.
> +
> config CMA_DEBUGFS
> bool "CMA debugfs interface"
> depends on CMA && DEBUG_FS
> diff --git a/mm/cma.c b/mm/cma.c
> index a4cfe995e11e..0ead392769b3 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -383,7 +383,7 @@ int __init cma_declare_contiguous_nid(phys_addr_t base,
> return ret;
> }
>
> -#ifdef CONFIG_CMA_DEBUG
> +#ifdef CONFIG_CMA_ALLOC_DEBUG
> static void cma_debug_show_areas(struct cma *cma)
> {
> unsigned long next_zero_bit, next_set_bit, nr_zero;
> --
> 2.17.1
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] cma: introduce CMA_ALLOC_DEBUG config
2023-08-09 13:16 [PATCH v2] cma: introduce CMA_ALLOC_DEBUG config Bibek Kumar Patro
2023-08-09 13:57 ` Bibek Kumar Patro
@ 2023-08-10 16:54 ` Andrew Morton
2023-08-11 6:54 ` Bibek Kumar Patro
2023-08-14 3:00 ` Pavan Kondeti
1 sibling, 2 replies; 7+ messages in thread
From: Andrew Morton @ 2023-08-10 16:54 UTC (permalink / raw)
To: Bibek Kumar Patro; +Cc: linux-mm, linux-kernel, quic_pkondeti, quic_charante
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] cma: introduce CMA_ALLOC_DEBUG config
2023-08-10 16:54 ` Andrew Morton
@ 2023-08-11 6:54 ` Bibek Kumar Patro
2023-08-14 3:00 ` Pavan Kondeti
1 sibling, 0 replies; 7+ messages in thread
From: Bibek Kumar Patro @ 2023-08-11 6:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, linux-kernel, quic_pkondeti, quic_charante
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] cma: introduce CMA_ALLOC_DEBUG config
2023-08-10 16:54 ` Andrew Morton
2023-08-11 6:54 ` Bibek Kumar Patro
@ 2023-08-14 3:00 ` Pavan Kondeti
2023-08-25 13:08 ` Bibek Kumar Patro
1 sibling, 1 reply; 7+ messages in thread
From: Pavan Kondeti @ 2023-08-14 3:00 UTC (permalink / raw)
To: Andrew Morton
Cc: Bibek Kumar Patro, linux-mm, linux-kernel, quic_pkondeti, quic_charante
Bibek,
On Thu, Aug 10, 2023 at 09:54:51AM -0700, 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?
IIUC, Andrew is asking/suggesting that would a runtime knob be useful
here?
For ex:
/proc/sys/vm/cma_dump_on_failure : This needs to be registerd in the
cma.c . grep for "register_sysctl_init" in mm code. We can set this to
true by default in case CMA_DEBUG is enabled so that current users are
not affected.
/sys/kernel/mm/cma/bitmap_dump_on_failure : This needs to stay in
cma_sysfs.c code
Thanks,
Pavan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] cma: introduce CMA_ALLOC_DEBUG config
2023-08-14 3:00 ` Pavan Kondeti
@ 2023-08-25 13:08 ` Bibek Kumar Patro
2023-08-28 3:18 ` Pavan Kondeti
0 siblings, 1 reply; 7+ messages in thread
From: Bibek Kumar Patro @ 2023-08-25 13:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, linux-kernel, Pavan Kondeti, quic_charante
On 8/14/2023 8:30 AM, Pavan Kondeti wrote:
> Bibek,
>
> On Thu, Aug 10, 2023 at 09:54:51AM -0700, 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?
>
Thanks Andrew for suggestion and Pavan for the details, tunable approach
looks viable too since we get to control this during runtime, but had
one query in mind where your inputs would help. In case any engineer
wishes to check boot time CMA failures, would it be easier to use a
CONFIG or /proc , /sys tunable?
(Assuming for /proc or /sys tunable, one has to modify the
init/post_boot scripts to mount the fs and set the tunable to true )
> IIUC, Andrew is asking/suggesting that would a runtime knob be useful
> here?
>
> For ex:
>
> /proc/sys/vm/cma_dump_on_failure : This needs to be registerd in the
> cma.c . grep for "register_sysctl_init" in mm code. We can set this to
> true by default in case CMA_DEBUG is enabled so that current users are
> not affected.
>
> /sys/kernel/mm/cma/bitmap_dump_on_failure : This needs to stay in
> cma_sysfs.c code
>
> Thanks,
> Pavan
>
>
Thanks,
Bibek
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] cma: introduce CMA_ALLOC_DEBUG config
2023-08-25 13:08 ` Bibek Kumar Patro
@ 2023-08-28 3:18 ` Pavan Kondeti
0 siblings, 0 replies; 7+ messages in thread
From: Pavan Kondeti @ 2023-08-28 3:18 UTC (permalink / raw)
To: Bibek Kumar Patro
Cc: Andrew Morton, linux-mm, linux-kernel, Pavan Kondeti, quic_charante
On Fri, Aug 25, 2023 at 06:38:13PM +0530, Bibek Kumar Patro wrote:
> On 8/14/2023 8:30 AM, Pavan Kondeti wrote:
> > Bibek,
> >
> > On Thu, Aug 10, 2023 at 09:54:51AM -0700, 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?
> >
>
> Thanks Andrew for suggestion and Pavan for the details, tunable approach
> looks viable too since we get to control this during runtime, but had
> one query in mind where your inputs would help. In case any engineer wishes
> to check boot time CMA failures, would it be easier to use a
> CONFIG or /proc , /sys tunable?
> (Assuming for /proc or /sys tunable, one has to modify the
> init/post_boot scripts to mount the fs and set the tunable to true )
>
Good point about on how to enable this during boot. A sysctl knob is
good here since it can be turned on/off via kernel commandline. This
means, you don't need to modify the kernel image and wait for the
userspace to come up. See
Documentation/admin-guide/kernel-parameters.txt (grep for sysctl) for
more details.
Thanks,
Pavan
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-08-28 3:20 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-09 13:16 [PATCH v2] cma: introduce CMA_ALLOC_DEBUG config Bibek Kumar Patro
2023-08-09 13:57 ` Bibek Kumar Patro
2023-08-10 16:54 ` Andrew Morton
2023-08-11 6:54 ` Bibek Kumar Patro
2023-08-14 3:00 ` Pavan Kondeti
2023-08-25 13:08 ` Bibek Kumar Patro
2023-08-28 3:18 ` Pavan Kondeti
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.