linux-kernel - Re: [patch 0/3] [Announcement] Performance Counters for Linux

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 5 Dec 2008 11:41:16 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	David Miller <davem@...emloft.net>, tglx@...utronix.de,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	akpm@...ux-foundation.org, eranian@...glemail.com,
	dada1@...mosbay.com, robert.richter@....com, arjan@...radead.org,
	hpa@...or.com, a.p.zijlstra@...llo.nl, rostedt@...dmis.org
Subject: Re: [patch 0/3] [Announcement] Performance Counters for Linux


* Paul Mackerras <paulus@...ba.org> wrote:

> Ingo Molnar writes:
> 
> > The 'target' task does not have to be stopped to offer counter 
> > virtualization (counter overcommit or counter scheduling) - or to offer 
> > any of the other performance counter features. Please let us know why it 
> > needs the task to be stopped - we asked about that on lkml in the perfmon 
> > thread and no technical answer was given, and couldnt find any such 
> > technical reason while implementing it ourselves.
> 
> I like this feature of your patchset, in fact, and the code looks 
> pretty clean (as I would expect :).  What I don't like (as I have 
> already said) is having to use an API that splits up the PMU into 
> pieces, plus the requirement that flows from that to have the kernel 
> know about the event selection logic on every CPU model we support.
> 
> One thing I haven't figured out yet is what happens if you have a 
> counter on a task and the task dies.  Can I still use the counter fd 
> after the task has died, and read out the total count?

yes, it will work just the way you'd expect it to work: the counter is 
attached to the fd of the monitoring task, so it does not go away. The 
counter simply stops counting but otherwise can be read even after the 
monitored task has exited.

We are also planning a natural 'the task has died' notification: a -EPIPE 
returned by read(), after the final count has been allowed to be read 
out. With blocking counters this will behave quite smoothly: instead of 
blocking indefinitely, we'd get back -EPIPE. Hm?

	Ingo
--
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/