| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 14 Jul 2008 18:38:58 +0200 From: Andi Kleen <andi@...stfloor.org> To: "Rafael C. de Almeida" <almeidaraf@...il.com> Cc: linux-kernel@...r.kernel.org Subject: Re: /proc/data information "Rafael C. de Almeida" <almeidaraf@...il.com> writes: > I'm interested in knowing how the cpu data from /proc/stat is gathered. > Following my way from this function: > > http://lxr.linux.no/linux+v2.6.25.10/fs/proc/proc_misc.c#L459 > > I've figured that the time is probably gathered using those > account_*_time on sched.c. I'm not sure where the times are read from, > though. They are normally (some architectures do it differently to cope with virtualized environments) sampled by a regular timer interrupt, which runs HZ times per second on each CPU. Common values for HZ is 250 (2.5ms interval), but you can compile with others too. I suspect the effects you're seeing all come from sampling error. The interval is also not fully stable because the kernel sometimes disables interrupts and that will delay the timer interrupt of course. How often this happens depends on the workload. Then there are architectures like s390 who do "microstate accounting": they keep track instead on every kernel entry/exit and every interrupt. That can be more accurate, but is also more costly. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists