On 05/02/2015 01:27 AM, Ingo Molnar wrote: > Regarding the user/kernel execution time split measurement: > > 1) the same flag could be used to sample a remote CPU's statistics > from another CPU and update the stats in the currently executing task. > As long as there's at least one non-nohz-full CPU, this would work. Or > are there systems were all CPUs are nohz-full?
On a NO_HZ_FULL system, you need at least one CPU to execute RCU callbacks, and do other system things like that, so there is at least one CPU that is not nohz_full. On NUMA systems, I could even see the sane option being one CPU that is not isolated or nohz_full per NUMA node, so we have a place to route irqs, etc... > 2) Alternatively we could just drive user/kernel split statistics from > context switches, which would be inaccurate if the workload is > SCHED_FIFO that only rarely context switches. > > How does this sound? I think option (1) sounds nicer :) What locks do we need, besides the runqueue lock to make sure the task does not go away, and later the task's vtime_lock to update its time statistics? Do we even need the lock_trace(task) as taken in proc_pid_stack(), since all we care is whether or not the thing is in kernel, user, or guest mode? For guest mode, we set a flag in the task struct somewhere, that part is easy. It also looks like dump_trace() can distinguish between normal, exception, and irq stacks. Not sure how fancy we need to get... -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
