stephane eranian wrote:
> I have spent most of last week restructuring the current perfmon2
> kernel code base to make it easier to isolate
> features. That should make it easier for the merge with mainline given
> that LKML people would like to receive
> small patches each adding one feature at a time.
Ah, this looks really good. I haven't really followed the perfmon2
progress over the last few releases. What is your plan for submission
to upstream inclusion? I guess if you want to have a chance of getting
it into 2.6.26, now would be the time to post the patches.
I can certainly offer some help getting it into shape for inclusion
if you're interested.
At some point I think you'll need a rebased git tree that contains
the changesets in exactly the way you want them to be merged,
and then you keep changing those patches, instead of adding new
changes on top.
> I have created a bunch of new files under perfmon/, each one
> implementing a feature or logically similar set of
> features. Similarly, I have also restructured the header files to
> separate the generic interface definition in
> perfmon.h from all the stuff needed by the kernel implementation, now
> in perfmon_kern.h. This model is replicated
> for each arch. Perfmon_const.h is gone.
I looked at the file structure now, and I think it can be done a little
bit better still:
* Since you can't build perfmon2 as a module, there is no point prefixing
the file names, so perfmon/perfmon_*.c can all be renamed to perfmon/*.c.
* include/linux/perfmon_{fmt,pmu,dfl_smpl}.h are all included only from
perfmon/*.c, not from arch code, so they can (and should) be moved to
perfmon/, to make it clearer what the interface to the arch is.
I also got the impression that part of perfmon_kern.h is only needed
by perfmon/*.c, not by the arch code, so that can be improved further,
but splitting it into perfmon/perfmon.h and include/linux/perfmon.h
* include/linux/perfmon.h contains an #ifdef CONFIG_PERFMON, which is
not valid for a user space header. Config symbols are never set in
user space, so this doesn't work.
* You need to list in include/*/Kbuild the files that should be
exported to user space, i.e. perfmon.h. Otherwise, "make headers_install"
doesn't pick them up
* asm-ia64/perfmon.h contains #ifdef __KERNEL__ around definitions that
are exported to user space on other architectures.
> Finally, there is a lot of work in the X86-specific perfmon.c. There
> is way too much model-specific
> code in there. I would like to see all of the P4 code outside of
> perfmon.c and into perfmon_p4.c. Similarly with
> the PEBS code. Note that the ds.h interface from Markus Metzger from
> Intel will help in hiding the access to the
> DS and PEBS information. Markus's patch is likely going to make it
> into 2.6.25 or .26. That should help us a bit.
I think it would be good to merge the architectures separately, through
the respective maintainers. If x86 is still behind by a bit, it could
wait another kernel release.
Arnd <><
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
perfmon2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
