Again, I'm not speaking as to what Linux does, exactly. But in general, things that are triggered on clocks and that _end_ before the next clock interrupt tend to be unnoticed when statistical sampling is used. If, for example, my clock-synchronized task consumes 90% of the CPU time before the next clock tick, but then finishes and goes idle, the sampler will never see it, and can report that the machine is 100% idle, when in fact it is only 10% idle.
Samplers work pretty well for tasks that run longer than that. If the tasks end up synchronized with the sampler, that's when the lies can creep in. (But it's not necessarily wrong, either. The true answer is: it depends.) If a task is still running when the sample is taken, then the accounting is a lot more accurate. Clock-driven sampling is simple and highly portable, and has been used in Unix since Day 1. To use things like TBR instead is a highly machine-dependent. An OS like Linux, which is also targeted for machines that do _not_ have a TBR or equivalent, probably does not use two or more entirely different implementations internally. (But ask an expert.) Yes, 'idle' is the balance of time. Idle + used will add up to 100%. -- Jim _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
