linux-kernel - Re: [PATCH 0/4] Finer granularity and task/cgroup irq time accounting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Aug 2010 11:09:13 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	balbir@...ux.vnet.ibm.com
Cc:	Venkatesh Pallipadi <venki@...gle.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	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 Tue, 2010-08-24 at 13:35 +0530, Balbir Singh wrote:
> * Peter Zijlstra <peterz@...radead.org> [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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/