- 14 10月, 2008 1 次提交
-
-
由 Andi Kleen 提交于
Newer Intel CPUs (Core1+) have support for architectural events described in CPUID 0xA. See the IA32 SDM Vol3b.18 for details. The advantage of this is that it can be done without knowing about the specific CPU, because the CPU describes by itself what performance events are supported. This is only a fallback because only a limited set of 6 events are supported. This allows to do profiling on Nehalem and on Atom systems (later not tested) This patch implements support for that in oprofile's Intel Family 6 profiling module. It also has the advantage of supporting an arbitary number of events now as reported by the CPU. Also allow arbitary counter widths >32bit while we're at it. Requires a patched oprofile userland to support the new architecture. v2: update for latest oprofile tree remove force_arch_perfmon Signed-off-by: NAndi Kleen <ak@linux.intel.com> Signed-off-by: NRobert Richter <robert.richter@amd.com>
-
- 24 9月, 2008 1 次提交
-
-
由 Robert Richter 提交于
Reverting commit 1a960b40 for the main branch. Multiplexing will be tracked on a separate feature branch. Conflicts: arch/x86/oprofile/nmi_int.c
-
- 26 7月, 2008 1 次提交
-
-
由 Jason Yeh 提交于
This patch introduces multiplexing support for the Oprofile kernel module. It basically adds a new function pointer in oprofile_operator allowing each architecture to supply its callback to switch between different sets of event when the timer expires. Userspace tools can modify the time slice through /dev/oprofile/time_slice. It also modifies the number of counters exposed to the userspace through /dev/oprofile. For example, the number of counters for AMD CPUs are changed to 32 and multiplexed in the sets of 4. Signed-off-by: NJason Yeh <jason.yeh@amd.com> Signed-off-by: NRobert Richter <robert.richter@amd.com> Cc: oprofile-list <oprofile-list@lists.sourceforge.net> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 17 4月, 2008 1 次提交
-
-
由 Paolo Ciarrocchi 提交于
no code changed: arch/x86/oprofile/op_model_ppro.o: text data bss dec hex filename 1765 0 16 1781 6f5 op_model_ppro.o.before 1765 0 16 1781 6f5 op_model_ppro.o.after md5: 71c7f68d2197d686e3d1121bc18a6b6e op_model_ppro.o.before.asm 71c7f68d2197d686e3d1121bc18a6b6e op_model_ppro.o.after.asm Signed-off-by: NPaolo Ciarrocchi <paolo.ciarrocchi@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 11 10月, 2007 1 次提交
-
-
由 Thomas Gleixner 提交于
Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 13 2月, 2007 1 次提交
-
-
由 Venkatesh Pallipadi 提交于
Handle these 32 bit perfmon counter MSR writes cleanly in oprofile. Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NAndi Kleen <ak@suse.de>
-
- 30 9月, 2006 1 次提交
-
-
由 Arun Sharma 提交于
Need to enable/disable all the counters instead of just counter 0. This affects all cpus with family=6, including i386/core. Usual symptom: only counter 0 provides samples. Other counters don't produce samples. Signed-off-by: NArun Sharma <arun.sharma@google.com> Cc: Philippe Elie <phil.el@wanadoo.fr> Cc: John Levon <levon@movementarian.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 26 9月, 2006 1 次提交
-
-
由 Don Zickus 提交于
Incorporates the new performance counter reservation system in oprofile. Also cleans up a lot of the initialization code. The code original zero'd out every register associated with performance counters regardless if those registers were used or not. This causes issues with the nmi watchdog. Now oprofile tries to reserve registers and gives up if it can't get them. Cc: levon@movementarian.org Cc: oprofile-list@lists.sf.net Signed-off-by: NDon Zickus <dzickus@redhat.com> Signed-off-by: NAndi Kleen <ak@suse.de>
-
- 27 6月, 2006 1 次提交
-
-
由 Don Zickus 提交于
Misc header cleanup for nmi watchdog. Signed-off-by: NDon Zickus <dzickus@redhat.com> Signed-off-by: NAndi Kleen <ak@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-