注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

火车的家

Put first thing first

 
 
 

日志

 
 

20131204 printk inside an interrupt handler , is it really that bad?  

2013-12-04 14:57:16|  分类: linux kernel |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

link

Question:

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 ?


Answer:

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.

  评论这张
 
阅读(379)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017