Re: [PATCH 1/7] cpu-timers: high-resolution CPU clocks for POSIXclock_* syscalls

[Roland McGrath]

> More interestingly (where "interesting" is defined as "could be really 
> nasty") it's likely to interact very badly in cases where we have some 
> _physically_ local clocks. Ie we might have some situation where we do 
> some node-local thing for intra-node scheduling, with some other clock for 
> inter-node scheduling. Exposing such a clock to a process that isn't 
> actually using it could result in the node-local clock source suddenly 
> needing to be exposed outside the node.

Not with the support I've written.  When you get the thread CPU time of any
thread but yourself, you just take ->sched_time as already stored and don't
do a sched_clock sample right then.  So you only see the amount of time
that has accrued as of that thread's last context switch or timer interrupt
(scheduler_tick), and not whatever amount is known only on the local CPU
where it is running right now.


Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/