Hi Stephane,
Thanks for your post.
I have a couple of questions for you:
1) After this initial x86-only patch has been accepted, will the next step
be to get other architecture ports accepted, or will something else come
first? As you might have guessed, we are interested in the getting POWER
re-introduced as early as possible.
2) From what you are saying, it sounds like integrating other non-x86
support will not be very difficult, and that we will be able to use the
existing arch-specific code almost unmodified from its current state since
it doesn't deal explicitly with multiplexing, nor sampling. The one area
of overlap may be "* no PMU description modules." Is that your view as
well?
Regards,
- Corey
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
[EMAIL PROTECTED]
Stephane Eranian wrote on 05/28/2008 03:06:31 PM:
>
> Hello everyone,
>
>
> Over the last few months, I have discussed with Andew Morton and Andi
> Kleen how we could
> merge perfmon2 with the mainline Linux kernel. From those discussions,
> he became clear
> the current code base could not be merged as is. It was too big and
> complex for LKML people
> to get a handle on.
>
> As you may have seen in 2.6.25, I have started major restructuring of
> the code to make it
> more modular and readable. That X86 support has been changed heavily
> to pushed all
> model-specific code into its corresponding PMU description module.
>
> The restructuring effort will continue in 2.6.26 along with some
> simplifications wherever
> possible.
>
> However, it became clear to me that it would be quite hard to split
> the code into manageable
> pieces to feed to LKML. So I have decided to take another approach,
> suggested by akpm
> and ak.
>
> I have started more or less from scratch, importing only selected bits
> and pieces from our
> current development tree.
>
> The first piece I want to focus on is per-thread monitoring, and in
> particular per-thread
> counting. Per-thread monitoring is a key value-add of perfmon. I
> think this needs to be
> in first.
>
> To that extent, I have created a separate tree which only contains
> enough code to
> support per-thread counting. This is limited to X86 processors only,
> both AMD and
> Intel. On the Intel side, so far only Intel Core-based processors are
> supported. The
> code has been stripped down to the bare minimum. Yet existing perfmon
> application
> and tools doing self-monitoring or monitoring of another thread can
> run unmodified
> assuming you use the current libpfm.
>
> The following functionalities are missing/changed for this
> lightweight version:
>
> * no system-wide monitoring
>
> * no kernel support for sampling
>
> * no sampling buffer formats
>
> * no PMU description modules. Mapping tables are compiled in.
>
> * no event set multiplexing
>
> * The following syscalls have been removed:
> - pfm_restart()
> - pfm_getinfo_evtsets()
> - pfm_create_evtsets()
> - pfm_delete_evtsets()
>
> * pfm_start() command has lost its (optional) argument (pfarg_start_t).
>
> * the context file descriptor is not readable, nor pollable. No
pfarg_msg_t
>
> * No signal is sent on 64-bit counter overflow. Yet 64-bit
> virtualization of the counters is maintained
>
> * Mutual exclusion with Oprofile is maintained.
>
> * PMU sharing with NMI watchdog is maintained
>
> * /sys/kernel/perfmon is maintained, though with fewer entries
>
> * debugfs statistics are maintained as compile time option
>
> * Itanium, MIPS, Power, SPARC supprt has been removed
>
> As a results the patch against 2.6.26-rc3 is 200KB and about 1900 lines
of C.
> I think I can squeeze it some more.
>
> As I said, certain tools and test programs still work because the
> shared data structures have not changed
> int size, though some fields have disappeared.
>
> Once I have something that works decently, I will probably create
> another GIT tree on kernel.org. Note
> that 200KB is too big for LKML, so the patch would have to be broken
> down some more.
>
> Hopefully with this codebase we will increase our chances of getting
> some pieces merged.
>
> Note that the current GIT tree is not abandonned, far from it. Instead
> it will remain the bleeding
> edge tree where all new developments must take place. Functionalities
> will then migrate from
> this tree to the merge tree and eventually to mainline.
>
> I would like to get something in good shape for Ottawa Linux Symposium
> (OLS) which is mid-July.
> Andi Kleen will deliver a paper/presentation on 'submitted patches for
> the kernel'. I'd like to show
> him we understand how to do this and are actively working on it
>
> Thanks.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
