All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 06/16] dyndbg: fix overcounting of ram used by dyndbg
@ 2019-10-29 20:00 Jim Cromie
  2019-10-29 20:47 ` Rasmus Villemoes
  0 siblings, 1 reply; 2+ messages in thread
From: Jim Cromie @ 2019-10-29 20:00 UTC (permalink / raw)
  To: jbaron, linux-kernel; +Cc: linux, greg, Jim Cromie

during dyndbg init, verbose logging prints its ram overhead.  But it
counted strlens of all ddebug callsite entries, which are full of
pointers into shared __dyndbg memory, and shouldnt be counted at all
(since theyre already in the __dyndbg section)

Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
 lib/dynamic_debug.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 540ca0861cf0..4ce0c53cdcfd 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -992,7 +992,6 @@ static int __init dynamic_debug_init(void)
 	char *cmdline;
 	int ret = 0;
 	int n = 0, entries = 0, modct = 0;
-	int verbose_bytes = 0;
 
 	if (__start___dyndbg == __stop___dyndbg) {
 		pr_warn("_ddebug table is empty in a CONFIG_DYNAMIC_DEBUG build\n");
@@ -1003,9 +1002,6 @@ static int __init dynamic_debug_init(void)
 	iter_start = iter;
 	for (; iter < __stop___dyndbg; iter++) {
 		entries++;
-		verbose_bytes += strlen(iter->modname) + strlen(iter->function)
-			+ strlen(iter->filename) + strlen(iter->format);
-
 		if (strcmp(modname, iter->modname)) {
 			modct++;
 			ret = ddebug_add_module(iter_start, n, modname);
@@ -1022,9 +1018,9 @@ static int __init dynamic_debug_init(void)
 		goto out_err;
 
 	ddebug_init_success = 1;
-	vpr_info("%d modules, %d entries and %d bytes in ddebug tables, %d bytes in (readonly) verbose section\n",
+	vpr_info("%d modules, %d entries and %d bytes in ddebug tables, %d bytes in (readonly) __dyndbg section\n",
 		 modct, entries, (int)(modct * sizeof(struct ddebug_table)),
-		 verbose_bytes + (int)(__stop___dyndbg - __start___dyndbg));
+		 (int)(__stop___dyndbg - __start___dyndbg));
 
 	/* apply ddebug_query boot param, dont unload tables on err */
 	if (ddebug_setup_string[0] != '\0') {
-- 
2.21.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH 06/16] dyndbg: fix overcounting of ram used by dyndbg
  2019-10-29 20:00 [PATCH 06/16] dyndbg: fix overcounting of ram used by dyndbg Jim Cromie
@ 2019-10-29 20:47 ` Rasmus Villemoes
  0 siblings, 0 replies; 2+ messages in thread
From: Rasmus Villemoes @ 2019-10-29 20:47 UTC (permalink / raw)
  To: Jim Cromie, jbaron, linux-kernel; +Cc: greg

On 29/10/2019 21.00, Jim Cromie wrote:
> during dyndbg init, verbose logging prints its ram overhead.  But it
> counted strlens of all ddebug callsite entries, which are full of
> pointers into shared __dyndbg memory, and shouldnt be counted at all
> (since theyre already in the __dyndbg section)

Hm. I agree we're probably overcounting, but the strings themselves do
not live in __dyndbg, but in .rodata. It's true that __FILE__ (and maybe
in a few cases ->format) get's deduplicated and by the nature of
__func__, ->function points at a unique-per-function string.

So I think the commit log is a bit misleading. However, I think the
patch is a good idea anyway: avoiding 4N strlen() calls during boot is a
good thing. And if anybody wants to know how much memory is used by the
pointed-to-strings, well, "wc dynamic_debug/control" should give an idea.

Rasmus

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-10-29 20:47 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-29 20:00 [PATCH 06/16] dyndbg: fix overcounting of ram used by dyndbg Jim Cromie
2019-10-29 20:47 ` Rasmus Villemoes

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.