bio.c: reduce verbosity at boot

PATCH In review Matthew Wilcox 7 participants 9 messages Aug 21, 2003 – Aug 25, 2003

Share & tools

Matthew Wilcox

author

2003-08-21 15:02 UTC #0 lore raw

PATCH 1/1 bio.c: reduce verbosity at boot

Linux is really far too verbose at boot time. I don't think these messages add anything to either the end user experience or debug ability.

Index: fs/bio.c
===================================================================
RCS file: /var/cvs/linux-2.6/fs/bio.c,v
retrieving revision 1.2

bio.c +0 -6

diff -u -p -r1.2 bio.c
@@ -793,10 +793,6 @@ static void __init biovec_init_pools(voi
 					mempool_free_slab, bp->slab);
 		if (!bp->pool)
 			panic("biovec: can't init mempool\n");
-
-		printk("biovec pool[%d]: %3d bvecs: %3d entries (%d bytes)\n",
-						i, bp->nr_vecs, pool_entries,
-						size);
 	}
 }

@@ -809,8 +805,6 @@ static int __init init_bio(void)
 	bio_pool = mempool_create(BIO_POOL_SIZE, mempool_alloc_slab, mempool_free_slab, bio_slab);
 	if (!bio_pool)
 		panic("bio: can't create mempool\n");
-
-	printk("BIO: pool of %d setup, %ZuKb (%Zd bytes/bio)\n", BIO_POOL_SIZE, BIO_POOL_SIZE * sizeof(struct bio) >> 10, sizeof(struct bio));
 
 	biovec_init_pools();

Signature · 3 lines

"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Jeff Garzik

2003-08-21 15:19 UTC #1 lore raw

Quoted 11 lines · Matthew Wilcox

Linux is really far too verbose at boot time. I don't think these messages add anything to either the end user experience or debug ability.
Index: fs/bio.c
===================================================================
RCS file: /var/cvs/linux-2.6/fs/bio.c,v
retrieving revision 1.2
diff -u -p -r1.2 bio.c

bio.c static void __init biovec_init_pools(voi · line 799

Quoted 7 lines

bio.c +0 -4

@@ -793,10 +793,6 @@ static void __init biovec_init_pools(voi
 					mempool_free_slab, bp->slab);
 		if (!bp->pool)
 			panic("biovec: can't init mempool\n");
-
-		printk("biovec pool[%d]: %3d bvecs: %3d entries (%d bytes)\n",
-						i, bp->nr_vecs, pool_entries,
-						size);

Although I agree with your "too verbose" sentiment above, I think the removing the messages outright might not serve the best interests the developer. Since even KERN_DEBUG still spams dmesg, in these situations I usually change these type of messages to be conditionally printed iff a debug macro is enabled.

As a tangent, the huge x86 IO-APIC verbosity really bugs me, too, and often is the direct cause of useful early printk messages being lost before boot is even complete.

Jeff

Lou Langholtz

2003-08-21 16:51 UTC #2 lore raw

Quoted 15 lines · Jeff Garzik

Quoted 13 lines · Matthew Wilcox
Linux is really far too verbose at boot time. I don't think these messages add anything to either the end user experience or debug ability.
Index: fs/bio.c
===================================================================
RCS file: /var/cvs/linux-2.6/fs/bio.c,v
retrieving revision 1.2
diff -u -p -r1.2 bio.c
bio.c 21 Aug 2003 14:58:40 -0000 renamed from bio.c 29 Jul 2003 17:25:49 -0000 1.2 +0 -0
@@ -793,10 +793,6 @@ static void __init biovec_init_pools(voi
                     mempool_free_slab, bp->slab);
         if (!bp->pool)

Quoted 8 lines

bio.c 21 Aug 2003 14:58:40 -0000 static void __init biovec_init_pools(voi · line 799
Quoted 5 lines
bio.c 21 Aug 2003 14:58:40 -0000 renamed from bio.c 29 Jul 2003 17:25:49 -0000 1.2 +0 -4
             panic("biovec: can't init mempool\n");
-
-        printk("biovec pool[%d]: %3d bvecs: %3d entries (%d bytes)\n",
-                        i, bp->nr_vecs, pool_entries,
-                        size);
. . . removing the messages outright might not serve the best interests the developer. Since even KERN_DEBUG still spams dmesg, in these situations I usually change these type of messages to be conditionally printed iff a debug macro is enabled.

How about using KERN_DEBUG and augmenting the dmesg store so that the level that is saved is configurable? Even compile time configurable seems reasonable to start. But axeing out even the possibility of boot time info seems bad to me.

Matthew Wilcox

author

2003-08-21 19:37 UTC #3 lore raw

Quoted 10 lines · Lou Langholtz

Quoted 4 lines · Jeff Garzik
. . . removing the messages outright might not serve the best interests the developer. Since even KERN_DEBUG still spams dmesg, in these situations I usually change these type of messages to be conditionally printed iff a debug macro is enabled.
How about using KERN_DEBUG and augmenting the dmesg store so that the level that is saved is configurable? Even compile time configurable seems reasonable to start. But axeing out even the possibility of boot time info seems bad to me.

But why is it interesting to have this information at boot time? As a user, I certainly don't care. As a developer, I don't find it interesting information. Maybe the maintainer of this particular piece of code finds it useful (Do you, Jens?), but does it need to be reported at boot time?

Perhaps it would be more useful to add some kind of reporting to mm/mempool.c along the same lines as /proc/slabinfo so we can get the dynamic information about pools at runtime rather than knowing their initial state at boot time.

Signature · 3 lines

"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Linus Torvalds

2003-08-21 19:55 UTC #4 lore raw

Quoted 4 lines · Matthew Wilcox

But why is it interesting to have this information at boot time? As a user, I certainly don't care. As a developer, I don't find it interesting information.

I do agree. The message may have been useful when the code was young and people wanted to see that it got executed correctly at all, but there doesn't seem to be a lot of point to it any more.

But hey, I'll leave it to the maintainer..

Linus

David Lang

2003-08-22 06:13 UTC #5 lore raw

Quoted 6 lines · Linus Torvalds

Quoted 4 lines · Matthew Wilcox
But why is it interesting to have this information at boot time? As a user, I certainly don't care. As a developer, I don't find it interesting information.

Quoted 7 lines

I do agree. The message may have been useful when the code was young and people wanted to see that it got executed correctly at all, but there doesn't seem to be a lot of point to it any more.
But hey, I'll leave it to the maintainer..
Linus

as a user I find a minimal set of messages (loading driver, hardware found) handy for identifying what hardware is actually in old machines I am given.

that said there is a lot of distance between that and the current situation where you print out 3-4 screens worth of info for a single driver.

David Lang

Jens Axboe

2003-08-25 18:28 UTC #6 lore raw

In reply to Linus Torvalds

Quoted 7 lines · Linus Torvalds

Quoted 4 lines · Matthew Wilcox
But why is it interesting to have this information at boot time? As a user, I certainly don't care. As a developer, I don't find it interesting information.

Quoted 5 lines

I do agree. The message may have been useful when the code was young and people wanted to see that it got executed correctly at all, but there doesn't seem to be a lot of point to it any more.
But hey, I'll leave it to the maintainer..

Willy's patch is fine with me as well. Purpose of the messages is long gone.

Signature · 1 line

Jens Axboe

Diego Calleja García

2003-08-21 20:31 UTC #7 lore raw

In reply to Lou Langholtz

Quoted 4 lines · El Thu, 21 Aug 2003 10:51:27 -0600 Lou Langholtz <[email protected]> escribió:

How about using KERN_DEBUG and augmenting the dmesg store so that the level that is saved is configurable? Even compile time configurable seems reasonable to start. But axeing out even the possibility of boot time info seems bad to me.

Like this?

(14) Kernel log buffer size (16 => 64KB, 17 => 128KB)

Available at least in 2.6.0-test3 under "General setup"

Lou Langholtz

2003-08-22 01:11 UTC #8 lore raw

Quoted 10 lines · Diego Calleja García

Quoted 3 lines · El Thu, 21 Aug 2003 10:51:27 -0600 Lou Langholtz <[email protected]> escribió:
How about using KERN_DEBUG and augmenting the dmesg store so that the level that is saved is configurable? Even compile time configurable seems reasonable to start. But axeing out even the possibility of boot time info seems bad to me.
Like this?
(14) Kernel log buffer size (16 => 64KB, 17 => 128KB) Available at least in 2.6.0-test3 under "General setup"

Yes, except I was thinking for loglevel rather than size. Is a loglevel option - as in only save printk's above level X in dmesg - already available? I've seen other emails fly by on the printk system before so this could well already be available. I haven't checked but was assuming from the emails I'd seen so far that this didn't exist and was merely suggesting this thinking it'd be an easy addition to the dmesg store.