On Mon, 2010-11-15 at 18:09 +0100, Michael Holzheu wrote: > > That you should not use sched_clock(), > > What should we use instead? Depends on what you want, look at kernel/sched_clock.c > > What does last departed mean? That is what timeline are you counting in? > > Do you want time as tasks see it, or time as your wallclock sees it? > > "last_depart" should be the time stamp, where the task has left a CPU > the last time. > > We assume that we can compare "last_depart" with "time_ns" in the > taskstats structure, I think you assume I actually know anything about taskstat :-), its the thing I always say =n to in my config file and have so far happily ignored all code of. > if we use task_rq(t)->clock for last_depart and > sched_clock() for stats->time_ns. Then you're up shit creek because rq->clock doesn't necessarily have any correlation to sched_clock(). > We also assume that we get wallclock > intervals in nanoseconds, if we look at two sched_clock() timestamps. Invalid assumption. > "stats->time_ns" is used as timestamp for the next snapshot query and > for calculation of the snapshot interval time. So there are three > important timestamps: > * struct task_struct: > sched_info.last_depart: Last time task has left CPU So you're essentially replicating the data in sched_entity::statistics::wait_start ? > * struct taskstats: > time_ns: Timestamp where taskstats data is generated > * sturuct cmd_pids: > time_ns: Timestamp for TASKSTATS_CMD_ATTR_PIDS command. > > Example: > 1. Get initial snapshot with cmd_pids->time_ns=0: > - All tasks are returned. > snapshot_time = MIN(stats->time_ns) for all received taskstats > 2. Get second snapshot with cmd_pids->time_ns = snapshot_time > - Only tasks that were active after "snapshot_time" are returned. /me can only hope all this will only increase overhead for those of us who actually use any of this.. I'm still upset over ->[us]timescaled existing, this patch set looks to me like it will only upset me more. -- 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
