Corey, On Thu, May 29, 2008 at 1:47 AM, Corey J Ashford <[EMAIL PROTECTED]> wrote: > 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. >
I think we could add the architectures so that everyone is at the same level. I see PPC, then MIPS, and SPARC. IA-64 is more problematic because there is already an earlier version of the interface in the kernel. If I remove it then there will immediately be a loss in functionalities (e.g., no more sampling). I need to think some more on how to do this one. > 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? > It does deal with sampling to some extent, even on X86, for instance for PEBS and IBS (both have been removed from this lightweight version). I have done some modifications to the arch/x86/perfmon/perfmon.c but it was to remove unused code. Same thing for the PMU description modules. A lot of this code can easily be added back. > > 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
