On Tue, 2010-11-16 at 13:16 +0100, Michael Holzheu wrote: > Ok, thanks. So sched_clock() seems to be a bad idea for our purposes. > > An alternative approach could be to have a global counter for the task > snapshots, which is increased each time a snapshot is created for > userspace. In addition to that we had to add a snapshot counter field to > the task_struct that is set to the current value of the global counter > each time a task leaves a CPU. Then userspace could ask for all tasks > that have been active after snapshot number x. In the response userspace > gets all tasks that have a snapshot number bigger than x together with > the new snapshot number y that can be used for the next query. > > Still it would be useful to add a timestamp of the creation of the > taskstats data in the response to userspace for calculating the interval > time between two snapshots. Would the usage of ktime_get() be valid for > that purpose? ktime_get() can be insanely slow, but yes that's an option. Another option is using local_clock() and living with the fact that it may be out of sync (up to a jiffy or so) between CPUs. The advantage of using ktime_get() as opposed to any other clock is that userspace has access to it as well through: clock_gettime(CLOCK_MONOTONIC), although that's arguably not too relevant when all you're interested in is deltas. -- 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
