企业官网建设流程全解析

绵阳建设局官方网站,大连网站设计九首选仟亿科技,建设银行网站查询密码是什么,个人网站建站系统文章目录1. 前言2. 现场3. 问题分析1. 前言 限于作者能力水平#xff0c;本文可能存在谬误#xff0c;因此而给读者带来的损失#xff0c;作者不做任何承诺。 2. 现场 通过 trace-cmd 抓如下事件#xff1a; ALSA事件#xff1a;hwptr, hw_mask_param, applptr调度事件…文章目录1. 前言2. 现场3. 问题分析1. 前言限于作者能力水平本文可能存在谬误因此而给读者带来的损失作者不做任何承诺。2. 现场通过trace-cmd抓如下事件ALSA事件hwptr, hw_mask_param, applptr调度事件sched_switch, sched_wakeup中断事件irq_handler_entry, irq_handler_exit具体数据如下latency-7395[002]22719.778930:hwptr:pcmC0D0c/sub0:POS:pos16,old26768,base26752,period64,buf128latency-7395[002]22719.778932:hwptr:pcmC0D0c/sub0:POS:pos16,old26768,base26752,period64,buf128latency-7395[002]22719.778934:hwptr:pcmC0D0c/sub0:POS:pos16,old26768,base26752,period64,buf128latency-7395[002]22719.778937:hwptr:pcmC0D0c/sub0:POS:pos48,old26768,base26752,period64,buf128latency-7395[002]22719.778938:applptr:pcmC0D0c/sub0:prev26768,curr26800,avail0,period64,buf128latency-7395[002]22719.778941:hwptr:pcmC0D0p/sub0:POS:pos96,old26816,base26752,period64,buf128latency-7395[002]22719.778942:applptr:pcmC0D0p/sub0:prev26896,curr26928,avail48,period64,buf128latency-7395[002]22719.778949:sched_switch:latency:7395[0]Skworker/2:1:5386[120]idle-0[007]22719.778971:irq_handler_entry:irq182namesnd_hda_intel:card0idle-0[007]22719.779013:hwptr:pcmC0D0c/sub0:IRQ:pos48,old26800,base26752,period64,buf128idle-0[007]22719.779070:irq_handler_exit:irq182rethandledidle-0[007]22719.779073:irq_handler_entry:irq182namesnd_hda_intel:card0idle-0[007]22719.779084:irq_handler_exit:irq182retunhandled kworker/2:1-5386[002]22719.779162:sched_wakeup:latency:7395[0]CPU:002idle-0[007]22719.780474:irq_handler_entry:irq182namesnd_hda_intel:card0idle-0[007]22719.780524:sched_wakeup:kworker/7:1:5655[120]CPU:007idle-0[007]22719.780567:hwptr:pcmC0D0p/sub0:IRQ:pos48,old26848,base26752,period64,buf128idle-0[007]22719.780567:xrun:pcmC0D0p/sub0:XRUN:old26928,base26880,period64,buf128idle-0[007]22719.780699:irq_handler_exit:irq182rethandledidle-0[007]22719.780701:irq_handler_entry:irq182namesnd_hda_intel:card0idle-0[007]22719.780729:irq_handler_exit:irq182retunhandledidle-0[007]22719.780736:sched_switch:swapper/7:0[120]Rkworker/7:1:5655[120]kworker/7:1-5655[007]22719.780744:sched_switch:kworker/7:1:5655[120]Wswapper/7:0[120]kworker/2:1-5386[002]22719.790242:sched_switch:kworker/2:1:5386[120]Rlatency:7395[0]latency-7395[002]22719.790455:hw_mask_param:pcmC0D0p:0000/025ACCESS0000000000000000ffffffffffffffff00000000000000000000000000000009latency-7395[002]22719.790455:hw_mask_param:pcmC0D0p:0000/025FORMAT0000000000000000ffffffffffffffff00000000000000000000000000000404latency-7395[002]22719.790456:hw_mask_param:pcmC0D0p:0000/025SUBFORMAT0000000000000000ffffffffffffffff000000000000000000000000000000013. 问题分析观察到有playback的XRUN日志idle-0[007]22719.780567:xrun:pcmC0D0p/sub0:XRUN:old26928,base26880,period64,buf128何解音频播放必须严格按照设定的采样频率、周期进行数据填充否则就会因为数据不足给的不及时而出现underrun现象因此对实时性有一定的要求。场景中使用48000Hz 采样率周期长度为64个采样这样每个周期的时长为64/48000 1.333ms。从日志看有好几个问题但最为突出的是进程latency-7395从时刻22719.778949被调度出去开始到时刻22719.790242再次被调度进来中间消耗了22719.790242 - 22719.790242 11.293ms也就意味着有约11.293ms向 playback 缓冲填充数据了这远远的超过了一个周期64/48000 1.333ms同时结合hwptr, applptr在 进程latency-7395被调度出去时剩余的数据不可能支撑11.293ms的消耗因此导致了playback underun。那么谁占住 CPU 不让进程latency-7395被调度进程latency-7395从时刻22719.778949被CPU-2被调度出去然后CPU-2转去kworker/2:1:5386然后就等待了11.293ms才被调度回来。进程latency-7395是一个实时进程来自alsa-lib/test/latency.c其优先级为0这怎么还让优先级为120的kworker/2:1:5386给占用了这么长时间呢答案是当前测试内核内调度 featureRT_RUNTIME_SHARE默认被关闭导致的详见链接: https://lore.kernel.org/lkml/c596a06773658d976fb839e02843a459ed4c2edf.1479204252.git.bristotredhat.com/可以通过命令消除该补丁的影响:sysctl-wkernel.sched_rt_runtime_us1000000然后再次测试不再有XRUN发生调查至此结束。