linux-kernel - Re: [discuss] Re: 2.6.19-rc5: known regressions (v3)

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:	Thu, 16 Nov 2006 10:34:56 -0500
From:	William Cohen <wcohen@...hat.com>
To:	Andi Kleen <ak@...e.de>
CC:	Andrew Morton <akpm@...l.org>, Linus Torvalds <torvalds@...l.org>,
	discuss@...-64.org, Eric Dumazet <dada1@...mosbay.com>,
	Komuro <komurojun-mbn@...ty.com>,
	Ernst Herzberg <earny@...4u.de>,
	Andre Noll <maan@...temlinux.org>,
	oprofile-list@...ts.sourceforge.net,
	Jens Axboe <jens.axboe@...cle.com>,
	linux-usb-devel@...ts.sourceforge.net, phil.el@...adoo.fr,
	Adrian Bunk <bunk@...sta.de>, Ingo Molnar <mingo@...hat.com>,
	Alan Stern <stern@...land.harvard.edu>,
	linux-pci@...ey.karlin.mff.cuni.cz,
	Stephen Hemminger <shemminger@...l.org>,
	Prakash Punnoor <prakash@...noor.de>,
	Len Brown <len.brown@...el.com>,
	Alex Romosan <romosan@...orax.lbl.gov>, gregkh@...e.de,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andrey Borzenkov <arvidjaar@...l.ru>
Subject: Re: [discuss] Re: 2.6.19-rc5: known regressions (v3)

Andi Kleen wrote:
> On Thursday 16 November 2006 06:05, Andrew Morton wrote:
> 
>>On Thu, 16 Nov 2006 04:21:09 +0100
>>Andi Kleen <ak@...e.de> wrote:
>>
>>
>>>>If it's really true that oprofile is simply busted then that's a serious
>>>>problem and we should find some way of unbusting it.  If that means just
>>>>adding a dummy "0" entry which always returns zero or something like that,
>>>>then fine.
>>>
>>>That could be probably done.
>>
>>I'm told that this is exactly what it was doing before it got changed.
> 
> 
> Hmm, ok perhaps that can be arranged again.
> 
> The trouble is that I want to use this performance counter for
> other purposes too, so we would run into trouble again 
> if oprofile keeps stealing it.

What other purposes do you see the performance counters useful for? To collect 
information on process characteristics so they can be scheduled more efficiently?

Is this going to require sharing the nmi interrupt and knowing which perfcounter 
register triggered the interrupt to get the correct action?  Currently the 
oprofile interrupt handler assumes any performance monitoring counter it sees 
overflowing is something it should count.

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