Hello Rob, On Tue, 2010-11-16 at 11:24 +0100, Rob van der Heij wrote: > If I understand the proposed solution, it remains a "sample based" > accounting. That means your granularity is limited by the rate with > which you can sample. When the cost of sampling is an order of > magnitude less, you can afford to sample more often and achieve higher > granularity at the same cost. High capture ratio is more important > than high granularity. I hope that with the proposed TASKSTATS_CMD_ATTR_PIDS command high capture ratio will be much less expensive compared to the procfs based approach. When using the tims_ns parameter, the more often you get a snapshot, the less tasks will have been active since the last snapshot. Of course this depends on the workload. But may I ask, why you think that a smaller sampling interval is so important? What is your use case? If we use an accounting tool that provides the cumulative times, all CPU time that has been consumed by dead tasks is aggregated in the cumulative time counters. No CPU time is lost. Therefore high frequency snapshots might be not so important. Note, that our current approach allows basically two mutually exclusive modes: 1. Use TASKSTATS_CMD_ATTR_PIDS command with time_ns=<last snapshot time> to only get tasks that have been active in the last interval. This is cheap and would allow high frequency accounting, but on the other hand does not allow the trick with the cumulative time. The tool "ptop_new" from patch 7/7 works with this mode. 2. Use TASKSTATS_CMD_ATTR_PIDS command with time_ns=0. This will always return all tasks, which is more expensive than approach 1, but allows the cumulative time accounting. But because all CPU time is collected, high frequency might not be needed. The tool "ptop_snap" from patch 7/7 works with this mode. Feel free and try out the patches and the userspace tools and give feedback to us. Michael -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
