Linux中time命令显示的用户和系统时间高得不可能

Question

我在包含~7000文件的目录中运行以下命令:

time find . | xargs -P8 -n1 grep -F 'xxx'

结果如下:

real    0m1.638s
user    1m1.090s
sys     0m5.080s

我很清楚(user+cpu)可以是< or > cpuTime，但是下面的界限应该成立:

(user + sys) < real * NCPU

其中NCPU为系统逻辑核数。在任何时刻，应该有最多的NCPU进程在运行，并被分配用户或系统时间。然而，我有12逻辑内核(6个真实内核x 2个超线程)，但是1.638 * 12 = ~20 seconds，而不知何故，我的进程设法消耗了超过一分钟的CPU时间。

主观上，1.6s的实时时间是正确的(我在更大的目录上尝试过)。

更改-P值会改变报告的实际时间和系统时间，但它在8-12附近的值附近趋于稳定。

请注意，没有一个文件包含xxx，但如果我使用一个字符串得到一些命中，结果是相同的。

Answer 1

最常见的"用户"one_answers"系统"时间计费机制是基于Linux中的周期性计时器。这种方法是不准确的，特别是对于短流程:

http://www.cs.rochester.edu/courses/252/spring2014/notes/XX_timing

Kernel使用定时中断来触发上下文切换，传递SIGALARM信号，跟踪一天的时间(字面上，通过计数)计时器滴答)，计划簿记任务等

内核保留每个进程的计时器次数计数中断处理程序发现它(进程)处于(a)用户模式，或(b)内核模式(系统)模式。这些计数的工作原理类似于Gprof给你们一个很好的感觉，在很长一段时间内的平均值进程运行的时间占了多少，占了多少它花在内核(系统). ...上因为统计抽样的粒度是大致的间隔定时相当于一个调度量子(~5-20ms)在低于100毫秒的时间内非常不准确。除此之外，它是只好到10%左右。它也倾向于对过程收费处理计时器中断的一些开销。作者报告说在他们的Linux系统上，这高估了4-5%的时间。

还有http://www.cs.toronto.edu/~demke/469F.06/Lectures/Lecture5.pdf幻灯片5,6,7"间隔计数的准确性"。

如果我们检查基本实现，我们知道"cpu"one_answers"系统"时间是在linux内核的kernel/timer.c文件中更新的，在"update_process_times"http://lxr.free-electrons.com/source/kernel/timer.c#L1349

1345 /*
1346  * Called from the timer interrupt handler to charge one tick to the current
1347  * process.  user_tick is 1 if the tick is user time, 0 for system.
1348  */
1349 void update_process_times(int user_tick)
1350 {
1351         struct task_struct *p = current;
1352         int cpu = smp_processor_id();
1353 
1354         /* Note: this timer irq context must be accounted for as well. */
1355         account_process_tick(p, user_tick);  // <<<<<<<<<<< here
1356         run_local_timers();
1357         rcu_check_callbacks(cpu, user_tick);
    ...
1362         scheduler_tick();
1363         run_posix_cpu_timers(p);
1364 }

update_process_times从tick_nohz_handler或tick_sched_timer -> tick_sched_handle (kernel/time/tick- schedule .c#L147)和从tick_handle_periodic -> tick_periodic (kernel/time/tick-common.c#L90)调用。我认为在某些情况下，update_process_times可能比timer interrupt更常被调用。