printk inside an interrupt handler , is it really that bad?
The printk
function is not just inserting into a queue/buffer -- assuming the log level is high enough, the output from printk
will be emitted to the console immediately, as part of the call to printk
. This is especially slow if the console is, say, on a serial port. But in any case, printk
does introduce pretty substantial overhead and can affect timing.
If you have a timing critical place where you want to get some debug output, you can look at using the trace_printk
function in modern kernels. This actually does just put input into the trace ringbuffer, and you can read it later. Take a look at this article for full details.
Comments
-
stdcall almost 2 years
everybody knows that interrupt handler should be short as possible. and adding functions like
printk
for debugging inside an interrupt handler is something that shouldn't be done. Actually, I tried it before when I was debugging the linux kernel for an interrupt driven char device I written, and it wrecked the timing of the driver.The question I have, is why this is happening ?
printk
function is buffered ! it means, as far as I understand that the data is inserted in to a queue, and it's being handled later, most probably after the interrupt handler is finished.So why doesn't it work ?
-
Roland over 12 yearsThe question is about
printk
, notprintf
which doesn't even exist in the kernel. And the Linux kernel'sprintk
is reentrant and can be called from interrupt context etc. So this answer is totally misguided. -
zvrba over 12 yearsUh, I misread the title, and the function name has a funky trailing character in his post :/
-
user31986 over 10 yearsHow is debugfs as an alternative to the trace_printk? Is it good enough or does it have any caveats too?
-
user31986 over 10 yearsSeriously what are you trying to add in to the discussion? I wonder why that reply is not marked negative!