[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080703100106.GA16792@elte.hu>
Date: Thu, 3 Jul 2008 12:01:06 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Barry Kasindorf <barry.kasindorf@....com>,
linux-kernel@...r.kernel.org,
Robert Richter <robert.richter@....com>,
the arch/x86 maintainers <x86@...nel.org>,
Stephane Eranian <eranian@...il.com>,
Jason Yeh <jason.yeh@....com>,
Arjan van de Ven <arjan@...radead.org>,
Markus Metzger <markus.t.metzger@...el.com>
Subject: Re: [PATCH 1/3] AMD Family10h+ IBS support for oProfile driver:
Setup routines
* Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Thu, 3 Jul 2008 11:20:52 +0200 Ingo Molnar <mingo@...e.hu> wrote:
>
> > 1) please rebase your patches ontop of -mm, which carries the
> > oprofile multiplexing cleanups and enhancements already which
> > heavily interact with your patchset.
>
> I dropped those. Because it's obvious that significant changes are to
> be made. So I guess working against linux-next is appropriate for
> this change.
hm, okay. All the pending oprofile enhancements are nice in principle
and there's like 3-4 oprofile topics that we should really start
reviewing, integrating and testing:
- the gist of the perfmon2 changes which make oprofile work across
context-switches. Oprofile should have done this from the get go.
- the oprofile syscall enhancements from perfmon2 for lightning-fast
profiling feedback.
- oprofile multiplexing: makes hw counter constraints largely invisible.
Should have been done years ago.
- new hw support like this IBS patch but it would also be nice to see
BTS/PEBS support perhaps.
- [ personally i'd love to see /debug/oprofile/prof.txt that would do
user-space-less parsing of oprofile data and would in essence
replace readprofile for all practical purposes. (while still being
as simple and self-contained as readprofile) Full in-kernel
generation of human-readable text output. This would be the thing
that would bring oprofile a lot closer to the average kernel
developer IMO. (Also, various knobs under /debug/oprofile/* to
configure oprofile details on the fly, without any userspace
dependencies.) ]
- [ oprofile .config driven in-kernel self-tests. Right now we notice it
quite late when it breaks. If we do /debug/oprofile/ that would be a
great step towards that. ]
tip/x86/oprofile (which already has some smaller changes) could host
them, if there's interest. It would be renamed to tip/oprofile or so,
kept separate and exported separately for import into -mm and/or
linux-next - not mixed into x86 and other -tip bits.
v2.6.28 stuff at the earliest, obviously.
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/
Powered by blists - more mailing lists