[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1282636286.2605.2307.camel@laptop>
Date: Tue, 24 Aug 2010 09:51:26 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Venkatesh Pallipadi <venki@...gle.com>
Cc: Martin Schwidefsky <schwidefsky@...ibm.com>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Balbir Singh <balbir@...ux.vnet.ibm.com>,
Paul Menage <menage@...gle.com>, linux-kernel@...r.kernel.org,
Paul Turner <pjt@...gle.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Paul Mackerras <paulus@...ba.org>,
Tony Luck <tony.luck@...el.com>
Subject: Re: [PATCH 0/4] Finer granularity and task/cgroup irq time
accounting
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists