Messages in this thread | | | Date | Tue, 8 Feb 2011 13:11:44 +0100 | From | Ingo Molnar <> | Subject | Re: RFC: /proc/<pid>/sched should contain cumulative data for all threads in process |
| |
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, 2011-02-07 at 16:29 -0600, Chris Friesen wrote: > > Hi, > > > > We've got a tool that gathers lots of scheduling data for each process > > (not task/thread) on the system. > > > > For /proc/<pid>/{stat,io} this is straightforward, as the per-thread > > values are summed together for the process as a whole. > > > > However, /proc/<pid>/sched only shows the data for the individual thread > > with the same tid as the pid. To get a per-process view we need to > > manually scan all the threads and sum them--and this can get expensive > > due to all the extra file operations, parsing, etc. > > > > Was this a concious design decision, or just an oversight? Would a > > patch converting it to whole-process values be accepted or is it enough > > of a standard interface that we can't break existing apps that expect > > the current behaviour? > > I'd as soon remove all that stuff than extend it, its an abi liability, > esp since you're talking about tools parsing this stuff.
So assuming a tool would want to capture such stats of the system, what would be its options? Could we do all this via system-wide counters and perf stat alike cheap, transparent gathering without having to patch/rebuild the kernel?
Thanks,
Ingo
| |