在dmesg中理解时间

我知道dmesg的时间是自启动以来的时间。 但我的具体问题是这个时间是在行中提到的过程的开始还是结束时计算的?

为什么这很重要?
举个例子:

 [ 4.352025] floppy0: no floppy controllers found [ 5.718270] random: nonblocking pool is initialized [ 94.134265] Adding 2094076k swap on /dev/sda5. Priority:-1 extents:1 across:2094076k FS** [ 96.988453] init: bootchart main process (274) terminated with status 127 

如果时间是在完成过程后计算的,则第3行中的过程应该负责慢速启动。
但是如果从过程开始计算时间,则应对第2行负责。

但是当我们在启动后很长时间检查dmesg时会变得更加复杂。
以此为例:

 [28047.749604] wlp3s0: associated [28941.112855] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=757985 end=757986) [31407.938694] cfg80211: World regulatory domain updated: [31407.938699] cfg80211: DFS Master region: unset 

这个2466s的差距不应该有任何有用的意义。

我看到很多次混淆dmesg哪一行应该负责缓慢启动。

我们怎样才能理解dmesg的时间?

dmesg不是对启动过程持续多长时间或有瓶颈的可靠测试。 根据Wikipedia page

最初启动时,计算机系统将其内核加载到内存中。 在此阶段,内核中存在的设备驱动程序被设置为驱动相关硬件。 这些驱动程序以及内核中的其他元素可能会生成输出(“消息”),报告模块的存在和所采用的任何参数的值

换句话说, dmesg本身只是收集信息,它是输出这些消息的驱动程序和其他系统进程,并且它们可以在任何时间点输出它们。 在这些消息之间可能存在或可能没有其他进程产生,因此它不是系统引导多长时间的指示。

dmesg还会从环形缓冲区连续收集消息,因此您的24​​66s延迟并不表示某些挂起过程,只是2466秒后发生的事件以及当时处于活动状态的任何进程只输出内核消息。

但是,您所需要的是启动图 ,它专门用于在启动过程中查找瓶颈。 我只看到它在多个论坛和本网站上被引用,但从未使用过我自己,所以不能给你更多的信息

dmesg命令通过/dev/kmsg使用用户空间访问模式读取内核的printk缓冲区。 每个条目都有一个单调的时间戳,以微秒单位 ,在创建日志条目时设置。

所以问题不能是,时间戳dmesg(或内核)将记录,但必须在内核为其执行的特定操作创建日志条目时。

我猜,这可能因行动而异。 当内核发生事件时,即插入USB设备时,内核会在有可用信息后立即记录。 当内核执行计划任务时,在作业完成时记录结果是有意义的。 如果它是一个复杂的工作,它可能会在它运行时产生一些日志条目,但正如我猜通常在发生了一些有趣的事情或者一些时间消失之后。

这里解释了如何访问内核的printk缓冲区。

因此,如果您特别想知道在操作的开头或结尾是否记录了某个条目,则需要在程序调用日志函数时查看内核或模块的代码。

阅读man dmesg ,特别是:

  -d, --show-delta Display the timestamp and time delta spent between messages. If used together with --notime then only the time delta without the timestamp is printed. -T, --ctime Print human readable timestamps. The timestamp could be inaccurate! The time source used for the logs is not updated after system SUSPEND/RESUME. 

时间戳值是“自启动/ 1000000后的微秒”(看起来像“秒到6位小数”)。时间戳在启动时设置为0

就像@cmks所说的那样,当日志条目插入内核的缓冲区时,“自启动以来的微秒”值被复制到日志条目中。 dmesg以几种不同的方式解释这个值。 dmesg -T -d | less dmesg -T -d | less会显示三角洲。 我确实读过了问题,以及@cmks的回答