linux-kernel - Re: Announce: Sysprof 1.1.2 CPU profiler 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	13 Oct 2009 22:13:54 +0200
From:	Soeren Sandmann <sandmann@...mi.au.dk>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Christoph Hellwig <hch@...radead.org>, linux-kernel@...r.kernel.org
Subject: Re: Announce: Sysprof 1.1.2 CPU profiler for Linux

Ingo Molnar <mingo@...e.hu> writes:

> * Christoph Hellwig <hch@...radead.org> wrote:
> 
> > On Sat, Sep 26, 2009 at 05:46:23PM +0200, Soeren Sandmann wrote:
> > > Sysprof 1.1.2 is now available. This is a development release leading
> > > up to a stable 1.2.0 release.
> > > 
> > > Sysprof is a sampling system-wide CPU profiler for Linux.  This
> > > version is based on the perf counter interface in 2.6.31 kernels and
> > > will not work with earlier kernels.
> > 
> > Btw, what is the plan for the sysprof ftrace plugin?  In general we 
> > move away from ftrace plugins towards trace events and perf, and if I 
> > remember correctly ftrace file format changes caused enough pain for 
> > sysprof that it kept shipping it's old hacky kernel module.

Missed this mail somehow. The main issue with the ftrace plugin was
performance. Often, 20% of the time, as reported by sysprof was spent
in the ftrace read() interface. I think some of that came from the
locking code compiled with debug information, but even without that,
there was significant overhead.

The perf counter interface works very well and will eventually allow a
number of new features to be added.

> > Is it time to deprectate the sysprof ftrace plugin?
> 
> Yes - but it's minimal maintenance overhead so we want to keep it for 
> kernel release or two, to sunset it properly.

Makes sense to me.



Thanks,
Soren

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