Re: [PATCH 0/4] Finer granularity and task/cgroup irq timeaccounting

[Peter Zijlstra]

On Tue, 2010-08-24 at 13:35 +0530, Balbir Singh wrote:
> * Peter Zijlstra <peterz@xxxxxxxxxxxxx> [2010-08-24 09:51:26]:
> 
> > On Thu, 2010-07-22 at 19:12 -0700, Venkatesh Pallipadi wrote:
> > > >
> > > > Well, the task and cgroup information is there but what does it really
> > > > tell me? As long as the irq & softirq time can be caused by any other
> > > > process I don't see the value of this incorrect data point.
> > > >
> > > 
> > > Data point will be correct. How it gets used is a different qn. This
> > > interface will be useful for Alert/Paranoid/Annoyed user/admin who
> > > sees that the job exec_time is high but it is not doing any useful
> > > work. 
> > 
> > I'm very sympathetic with Martin's POV. irq/softirq times per task don't
> > really make sense. In the case you provide above the solution would be
> > to subtract these times from the task execution time, not break it out.
> > In that case he would see his task not do much, and end up with the same
> > action list.
> >
> 
> cgroup level info does make sense, assuming that tasks that share the
> costs being mentioned here belong to the same cgroup. 

I don't think that's a valid assumption.

If its not true for tasks, then its not true for groups of tasks either.
It might be slightly less wrong due to the larger number of entities
reducing the error bounds, but its still wrong in principle.

The whole attribution mess can only be solved by actually splitting out
the entries that do work, like per-cgroup workqueue threads and similar
things.

System wide entities like IRQs are very hard to attribute correctly like
Martin already argued, and I don't think its worth doing.
--
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/