Re: [PATCH 3/9] printk: add CON_ALLDATA console flag

[JÃrn Engel]

On Fri, 1 March 2013 10:08:00 -0500, Jeff Moyer wrote:
> 
> People don't just use this for "debugging sessions."  They use it in
> production, and I already gave you one reason why you might not want to
> do this with netconsole (udp is unreliable, and I've definitely seem
> cases where netconsole suffered due to dropped packets; this won't make
> that better, especially when you multiply the extra bytes times the
> number of servers on the subnet).

I think I maintain a fairly sizeable production setup with netconsole.
A few hundred machines run netconsole and send all messages to a
single recipient.  And all those machines have the patch we are
discussing applied.  That has caused roughly zero problems so far.

We constantly see problems with netconsole and presumably packet loss
(haven't checked yet) when show_state() runs.  That amount of load
appears to be too much for the network.  Regular production netconsole
is utterly unimpressed in my network, with or without CON_ALLDATA.

Which is not to say you are wrong.  It just means that noone has shown
an example supporting your argument yet, while I have one supporting
mine.

More fundamentally, I believe the console log levels used to make
sense when systems had exactly one console.  With multiple consoles
and vastly different properties of those consoles, you simply cannot
find one good answer for all.  A 9600 baud serial console will usually
add several seconds to your boot process, so eliminating extra
messages is hugely important.  Blockconsole can take several megabytes
a second without blinking, so the cost of extra messages is near-zero,
while the benefit remains identical.

Maybe the correct solution would be to have a separate loglevel for
each console.  I don't know.  For my purposes the coarser CON_ALLDATA
approach is good enough.

JÃrn

--
"Security vulnerabilities are here to stay."
-- Scott Culp, Manager of the Microsoft Security Response Center, 2001
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/