On Tue, 6 May 2014 14:12:34 +0100 Will Deacon <will.deacon@xxxxxxx> wrote: > > > > My opinion is that when you are printing from each and every interrupt > > > > which happens so often, then you have a problem and disabling IRQs in > > > > printk so that your interrupt doesn't happen that often seems like a poor > > > > solution to me. You could as well just ratelimit your debug messages, > > > > couldn't you? > > > > > > My use-case was basically using printk as a debug trace during early boot > > > when bringing up Linux on a new CPU core. I don't think ratelimiting would > > > be the right thing there, since I really did want as many messages to > > > reach the console as possible (which is also why I wrote this patch, not > > > just the other one in the series). > > OK, I understand. It just seems wrong to me to throttle all interrupts on > > the cpu while doing printing just because someone might be doing debug > > printing from the interrupt. Sure it's fine as a debug hack but on a > > production machine that seems rather counterproductive. > > Perhaps, but the one time I *really* want printk to be reliable is when I'm > using it to debug a problem. If you're debugging a problem, you're able to alter printk! So perhaps one way out of this is some developer-only ifdef to robustify printk for particular usage patterns. -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
