You can subscribe to this list here.
2001 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
(3) |
May
(3) |
Jun
(7) |
Jul
(10) |
Aug
(1) |
Sep
(50) |
Oct
(74) |
Nov
(28) |
Dec
(32) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(63) |
Feb
(27) |
Mar
(88) |
Apr
(21) |
May
(59) |
Jun
(41) |
Jul
(61) |
Aug
(89) |
Sep
(179) |
Oct
(152) |
Nov
(190) |
Dec
(92) |
2003 |
Jan
(140) |
Feb
(160) |
Mar
(193) |
Apr
(107) |
May
(84) |
Jun
(60) |
Jul
(97) |
Aug
(97) |
Sep
(42) |
Oct
(105) |
Nov
(99) |
Dec
(52) |
2004 |
Jan
(99) |
Feb
(97) |
Mar
(62) |
Apr
(73) |
May
(94) |
Jun
(37) |
Jul
(32) |
Aug
(89) |
Sep
(87) |
Oct
(72) |
Nov
(114) |
Dec
(35) |
2005 |
Jan
(25) |
Feb
(42) |
Mar
(120) |
Apr
(151) |
May
(71) |
Jun
(36) |
Jul
(35) |
Aug
(92) |
Sep
(19) |
Oct
(57) |
Nov
(77) |
Dec
(61) |
2006 |
Jan
(107) |
Feb
(114) |
Mar
(66) |
Apr
(101) |
May
(74) |
Jun
(64) |
Jul
(42) |
Aug
(51) |
Sep
(106) |
Oct
(118) |
Nov
(138) |
Dec
(162) |
2007 |
Jan
(148) |
Feb
(222) |
Mar
(73) |
Apr
(160) |
May
(166) |
Jun
(125) |
Jul
(184) |
Aug
(58) |
Sep
(41) |
Oct
(102) |
Nov
(111) |
Dec
(52) |
2008 |
Jan
(104) |
Feb
(67) |
Mar
(48) |
Apr
(125) |
May
(114) |
Jun
(98) |
Jul
(206) |
Aug
(89) |
Sep
(88) |
Oct
(163) |
Nov
(115) |
Dec
(113) |
2009 |
Jan
(131) |
Feb
(85) |
Mar
(157) |
Apr
(198) |
May
(202) |
Jun
(154) |
Jul
(156) |
Aug
(75) |
Sep
(80) |
Oct
(148) |
Nov
(88) |
Dec
(83) |
2010 |
Jan
(78) |
Feb
(59) |
Mar
(89) |
Apr
(54) |
May
(92) |
Jun
(66) |
Jul
(38) |
Aug
(73) |
Sep
(84) |
Oct
(91) |
Nov
(52) |
Dec
(62) |
2011 |
Jan
(86) |
Feb
(68) |
Mar
(129) |
Apr
(121) |
May
(154) |
Jun
(81) |
Jul
(55) |
Aug
(55) |
Sep
(58) |
Oct
(115) |
Nov
(88) |
Dec
(95) |
2012 |
Jan
(105) |
Feb
(62) |
Mar
(52) |
Apr
(54) |
May
(103) |
Jun
(89) |
Jul
(152) |
Aug
(73) |
Sep
(58) |
Oct
(60) |
Nov
(52) |
Dec
(90) |
2013 |
Jan
(102) |
Feb
(63) |
Mar
(68) |
Apr
(128) |
May
(82) |
Jun
(94) |
Jul
(87) |
Aug
(29) |
Sep
(24) |
Oct
(25) |
Nov
(40) |
Dec
(51) |
2014 |
Jan
(41) |
Feb
(60) |
Mar
(33) |
Apr
(22) |
May
(38) |
Jun
(23) |
Jul
(86) |
Aug
(113) |
Sep
(23) |
Oct
(22) |
Nov
(18) |
Dec
(13) |
2015 |
Jan
(40) |
Feb
(12) |
Mar
(28) |
Apr
(32) |
May
(53) |
Jun
(65) |
Jul
(27) |
Aug
(6) |
Sep
(13) |
Oct
(25) |
Nov
(48) |
Dec
(19) |
2016 |
Jan
(5) |
Feb
(10) |
Mar
(23) |
Apr
(31) |
May
(19) |
Jun
(28) |
Jul
(19) |
Aug
(2) |
Sep
(9) |
Oct
(18) |
Nov
(10) |
Dec
(4) |
2017 |
Jan
(23) |
Feb
(42) |
Mar
(13) |
Apr
(5) |
May
(7) |
Jun
(26) |
Jul
(13) |
Aug
(8) |
Sep
(1) |
Oct
(3) |
Nov
(27) |
Dec
(4) |
2018 |
Jan
(9) |
Feb
(22) |
Mar
(27) |
Apr
(16) |
May
(7) |
Jun
(5) |
Jul
(7) |
Aug
(1) |
Sep
(36) |
Oct
(17) |
Nov
(1) |
Dec
(5) |
2019 |
Jan
(1) |
Feb
|
Mar
(11) |
Apr
(4) |
May
(7) |
Jun
(6) |
Jul
(9) |
Aug
(4) |
Sep
(6) |
Oct
(4) |
Nov
(5) |
Dec
(13) |
2020 |
Jan
(60) |
Feb
(57) |
Mar
(4) |
Apr
(71) |
May
(1) |
Jun
(1) |
Jul
(7) |
Aug
(11) |
Sep
(6) |
Oct
|
Nov
(2) |
Dec
|
2021 |
Jan
(42) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <no...@so...> - 2003-01-02 16:04:14
|
Bugs item #554927, was opened at 2002-05-11 19:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=554927&group_id=16191 Category: None Group: None Status: Open Resolution: None Priority: 9 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: Power management + BIOS not supported in 2.4 Initial Comment: OProfile has no support for power management and the BIOS mode found on laptops. This means it can crash if these features are used. (This bug is impossible to fix on some broken laptops) ---------------------------------------------------------------------- >Comment By: Philippe Elie (phil_e) Date: 2003-01-02 17:04 Message: Logged In: YES user_id=318973 Your problem is different, module correctly check than your latop doesn't contain a local APIC but can't fall back to RTC mode because RTC is already in use: see: http://oprofile.sourceforge.net/doc/detailed-parameters.html#rtc regards, Phil ---------------------------------------------------------------------- Comment By: Jerry Quinn (jlquinn) Date: 2003-01-02 16:37 Message: Logged In: YES user_id=311165 I may be a victim of this bug. I'm using an IBM T30 with debian woody, 2.4.20, and power management enabled. I rebuilt a kernel, built the oprofile to match. When I try to start oprofile, I see the following message and the machine locks up hard: /lib/modules/2.4.20-686/oprofile/oprofile.o: no local P6 APIC. Fallinng back to RTC mode. Your CPU does not have a local APIC, e.g. mobile P6. Falling back to RTC mode. oprofile: can't get RTC I/O ports /lib/modules/2.4.20-686/oprofile/oprofile.o: init_module: Device or resource busy No messages make it to any log files. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2002-09-18 17:39 Message: Logged In: YES user_id=53034 We need to use the apic_pm_register() API I believe. However, this is not exported to modules. More seriously, we do not use the dmi_scan blacklist so we will crash and burn horribly on laptops that /do/ have a local APIC, but where it is broken, or APM is broken. ---------------------------------------------------------------------- Comment By: William Cohen (wcohen) Date: 2002-09-18 17:24 Message: Logged In: YES user_id=542804 On the Dell inspiron 4100 laptop this problem seems to be a result of OProfile not informing the kernel that it is using the APIC (Advanced Programmable Interrupt Controller). The newer versions of the Linux kernel (e.g. 2.4.18) have some support to turn off the APIC before the BIOS is used for power management and prevent the machine from crashing. However, it does not restore the APIC to the proper state and OProfile still does not work. In theory, the RTC mode should not suffer from the bad interaction between OProfile's use of APIC and power management. -Will ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=554927&group_id=16191 |
From: <no...@so...> - 2003-01-02 15:37:21
|
Bugs item #554927, was opened at 2002-05-11 17:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=554927&group_id=16191 Category: None Group: None Status: Open Resolution: None Priority: 9 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: Power management + BIOS not supported in 2.4 Initial Comment: OProfile has no support for power management and the BIOS mode found on laptops. This means it can crash if these features are used. (This bug is impossible to fix on some broken laptops) ---------------------------------------------------------------------- Comment By: Jerry Quinn (jlquinn) Date: 2003-01-02 15:37 Message: Logged In: YES user_id=311165 I may be a victim of this bug. I'm using an IBM T30 with debian woody, 2.4.20, and power management enabled. I rebuilt a kernel, built the oprofile to match. When I try to start oprofile, I see the following message and the machine locks up hard: /lib/modules/2.4.20-686/oprofile/oprofile.o: no local P6 APIC. Fallinng back to RTC mode. Your CPU does not have a local APIC, e.g. mobile P6. Falling back to RTC mode. oprofile: can't get RTC I/O ports /lib/modules/2.4.20-686/oprofile/oprofile.o: init_module: Device or resource busy No messages make it to any log files. ---------------------------------------------------------------------- Comment By: John Levon (movement) Date: 2002-09-18 15:39 Message: Logged In: YES user_id=53034 We need to use the apic_pm_register() API I believe. However, this is not exported to modules. More seriously, we do not use the dmi_scan blacklist so we will crash and burn horribly on laptops that /do/ have a local APIC, but where it is broken, or APM is broken. ---------------------------------------------------------------------- Comment By: William Cohen (wcohen) Date: 2002-09-18 15:24 Message: Logged In: YES user_id=542804 On the Dell inspiron 4100 laptop this problem seems to be a result of OProfile not informing the kernel that it is using the APIC (Advanced Programmable Interrupt Controller). The newer versions of the Linux kernel (e.g. 2.4.18) have some support to turn off the APIC before the BIOS is used for power management and prevent the machine from crashing. However, it does not restore the APIC to the proper state and OProfile still does not work. In theory, the RTC mode should not suffer from the bad interaction between OProfile's use of APIC and power management. -Will ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=554927&group_id=16191 |
From: Richard H. <rt...@tw...> - 2002-12-22 13:08:20
|
I haven't actually tried this out yet. But, hey, it compiles. Posting it here just in case someone wants to review the interface with the generic code. r~ You can import this changeset into BK by piping this whole message to: '| bk receive [path to repository]' or apply the patch as usual. =================================================================== ChangeSet@1.939, 2002-12-22 04:53:09-08:00, rt...@do... [OPROFILE] First cut at oprofile support for Alpha. arch/alpha/Kconfig | 1 arch/alpha/Makefile | 7 - arch/alpha/kernel/irq_alpha.c | 2 arch/alpha/oprofile/Kconfig | 23 ++++ arch/alpha/oprofile/Makefile | 14 ++ arch/alpha/oprofile/common.c | 179 +++++++++++++++++++++++++++++++++ arch/alpha/oprofile/op_impl.h | 49 +++++++++ arch/alpha/oprofile/op_model_ev4.c | 99 ++++++++++++++++++ arch/alpha/oprofile/op_model_ev5.c | 198 +++++++++++++++++++++++++++++++++++++ arch/alpha/oprofile/op_model_ev6.c | 91 +++++++++++++++++ drivers/oprofile/oprofile_stats.c | 1 include/linux/oprofile.h | 12 ++ 12 files changed, 671 insertions, 5 deletions diff -Nru a/arch/alpha/Kconfig b/arch/alpha/Kconfig --- a/arch/alpha/Kconfig Sun Dec 22 04:54:22 2002 +++ b/arch/alpha/Kconfig Sun Dec 22 04:54:22 2002 @@ -942,6 +942,7 @@ source "net/bluetooth/Kconfig" +source "arch/alpha/oprofile/Kconfig" menu "Kernel hacking" diff -Nru a/arch/alpha/Makefile b/arch/alpha/Makefile --- a/arch/alpha/Makefile Sun Dec 22 04:54:22 2002 +++ b/arch/alpha/Makefile Sun Dec 22 04:54:22 2002 @@ -92,9 +92,10 @@ HEAD := arch/alpha/kernel/head.o -core-y += arch/alpha/kernel/ arch/alpha/mm/ -core-$(CONFIG_MATHEMU) += arch/alpha/math-emu/ -libs-y += arch/alpha/lib/ +core-y += arch/alpha/kernel/ arch/alpha/mm/ +core-$(CONFIG_MATHEMU) += arch/alpha/math-emu/ +drivers-$(CONFIG_OPROFILE) += arch/alpha/oprofile/ +libs-y += arch/alpha/lib/ export libs-y diff -Nru a/arch/alpha/kernel/irq_alpha.c b/arch/alpha/kernel/irq_alpha.c --- a/arch/alpha/kernel/irq_alpha.c Sun Dec 22 04:54:22 2002 +++ b/arch/alpha/kernel/irq_alpha.c Sun Dec 22 04:54:22 2002 @@ -74,7 +74,7 @@ alpha_mv.device_interrupt(vector, regs); return; case 4: - perf_irq(vector, regs); + perf_irq(la_ptr, regs); return; default: printk(KERN_CRIT "Hardware intr %ld %lx? Huh?\n", diff -Nru a/arch/alpha/oprofile/Kconfig b/arch/alpha/oprofile/Kconfig --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/arch/alpha/oprofile/Kconfig Sun Dec 22 04:54:22 2002 @@ -0,0 +1,23 @@ + +menu "Profiling support" + depends on EXPERIMENTAL + +config PROFILING + bool "Profiling support (EXPERIMENTAL)" + help + Say Y here to enable the extended profiling support mechanisms used + by profilers such as OProfile. + + +config OPROFILE + tristate "OProfile system profiling (EXPERIMENTAL)" + depends on PROFILING + help + OProfile is a profiling system capable of profiling the + whole system, include the kernel, kernel modules, libraries, + and applications. + + If unsure, say N. + +endmenu + diff -Nru a/arch/alpha/oprofile/Makefile b/arch/alpha/oprofile/Makefile --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/arch/alpha/oprofile/Makefile Sun Dec 22 04:54:22 2002 @@ -0,0 +1,14 @@ +obj-$(CONFIG_OPROFILE) += oprofile.o + +DRIVER_OBJS = $(addprefix ../../../drivers/oprofile/, \ + oprof.o cpu_buffer.o buffer_sync.o \ + event_buffer.o oprofile_files.o \ + oprofilefs.o oprofile_stats.o ) + +oprofile-y := $(DRIVER_OBJS) common.o +oprofile-$(CONFIG_ALPHA_GENERIC) += op_model_ev4.o \ + op_model_ev5.o \ + op_model_ev6.o +oprofile-$(CONFIG_ALPHA_EV4) += op_model_ev4.o +oprofile-$(CONFIG_ALPHA_EV5) += op_model_ev5.o +oprofile-$(CONFIG_ALPHA_EV6) += op_model_ev6.o diff -Nru a/arch/alpha/oprofile/common.c b/arch/alpha/oprofile/common.c --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/arch/alpha/oprofile/common.c Sun Dec 22 04:54:22 2002 @@ -0,0 +1,179 @@ +/** + * @file arch/alpha/oprofile/common.c + * + * @remark Copyright 2002 OProfile authors + * @remark Read the file COPYING + * + * @author Richard Henderson <rt...@tw...> + */ + +#include <linux/oprofile.h> +#include <linux/init.h> +#include <linux/smp.h> +#include <linux/errno.h> +#include <asm/ptrace.h> +#include <asm/system.h> + +#include "op_impl.h" + +extern struct op_axp_model op_model_ev4 __attribute__((weak)); +extern struct op_axp_model op_model_ev5 __attribute__((weak)); +extern struct op_axp_model op_model_pca56 __attribute__((weak)); +extern struct op_axp_model op_model_ev6 __attribute__((weak)); + +static struct op_axp_model *model; + +extern void (*perf_irq)(unsigned long, struct pt_regs *); +static void (*save_perf_irq)(unsigned long, struct pt_regs *); + +static struct op_counter_config ctr[3]; +static struct op_system_config sys; +static struct op_register_config reg; + +/* Called from do_entInt to handle the performance monitor interrupt. */ + +static void +op_handle_interrupt(unsigned long which, struct pt_regs *regs) +{ + /* EV4 can't properly disable counters individually. + Discard "disabled" events now. */ + if (!ctr[which].enabled) + return; + + /* Record the sample. */ + oprofile_add_sample(regs->pc, which, smp_processor_id()); + + /* If the user has selected an interrupt frequency that is + not exactly the width of the counter, write a new value + into the counter such that it'll overflow after N more + events. */ + if ((reg.need_reset >> which) & 1) + model->reset_ctr(®, which); +} + +static int +op_axp_setup(void) +{ + unsigned long i, e; + + /* Install our interrupt handler into the existing hook. */ + save_perf_irq = perf_irq; + perf_irq = op_handle_interrupt; + + /* Compute the mask of enabled counters. */ + for (i = e = 0; i < model->num_counters; ++i) + if (ctr[0].enabled) + e |= 1 << i; + reg.enable = e; + + /* Pre-compute the values to stuff in the hardware registers. */ + model->reg_setup(®, ctr, &sys); + + /* Configure the registers on all cpus. */ + smp_call_function(model->cpu_setup, ®, 0, 1); + model->cpu_setup(®); + return 0; +} + +static void +op_axp_shutdown(void) +{ + /* Remove our interrupt handler. We may be removing this module. */ + perf_irq = save_perf_irq; +} + +static void +op_axp_cpu_start(void *dummy) +{ + wrperfmon(1, reg.enable); +} + +static int +op_axp_start(void) +{ + smp_call_function(op_axp_cpu_start, NULL, 0, 1); + op_axp_cpu_start(NULL); + return 0; +} + +static inline void +op_axp_cpu_stop(void *dummy) +{ + /* Disable performance monitoring for all counters. */ + wrperfmon(0, -1); +} + +static void +op_axp_stop(void) +{ + smp_call_function(op_axp_cpu_stop, NULL, 0, 1); + op_axp_cpu_stop(NULL); +} + +static int +op_axp_create_files(struct super_block * sb, struct dentry * root) +{ + int i; + + for (i = 0; i < model->num_counters; ++i) { + struct dentry *dir; + char buf[2]; + + buf[0] = i + '0'; + buf[1] = 0; + dir = oprofilefs_mkdir(sb, root, buf); + + oprofilefs_create_ulong(sb, dir, "enabled", &ctr[i].enabled); + oprofilefs_create_ulong(sb, dir, "event", &ctr[i].event); + oprofilefs_create_ulong(sb, dir, "count", &ctr[i].count); + } + + if (model->can_set_proc_mode) { + oprofilefs_create_ulong(sb, root, "enable_pal", + &sys.enable_pal); + oprofilefs_create_ulong(sb, root, "enable_kernel", + &sys.enable_kernel); + oprofilefs_create_ulong(sb, root, "enable_user", + &sys.enable_user); + } + + return 0; +} + +static struct oprofile_operations oprof_axp_ops = { + .create_files = op_axp_create_files, + .setup = op_axp_setup, + .shutdown = op_axp_shutdown, + .start = op_axp_start, + .stop = op_axp_stop +}; + +int __init +oprofile_arch_init(struct oprofile_operations **ops, enum oprofile_cpu *cpu) +{ + switch (implver()) { + case IMPLVER_EV4: + model = &op_model_ev4; + break; + case IMPLVER_EV5: + /* 21164PC has a slightly different set of events. + Recognize the chip by the presence of the MAX insns. */ + if (!amask(AMASK_MAX)) + model = &op_model_pca56; + else + model = &op_model_ev5; + break; + case IMPLVER_EV6: + model = &op_model_ev6; + break; + default: + model = NULL; + } + + if (!model) + return ENODEV; + + *ops = &oprof_axp_ops; + *cpu = model->cpu; + return 0; +} diff -Nru a/arch/alpha/oprofile/op_impl.h b/arch/alpha/oprofile/op_impl.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/arch/alpha/oprofile/op_impl.h Sun Dec 22 04:54:22 2002 @@ -0,0 +1,49 @@ +/** + * @file arch/alpha/oprofile/op_impl.h + * + * @remark Copyright 2002 OProfile authors + * @remark Read the file COPYING + * + * @author Richard Henderson <rt...@tw...> + */ + +#ifndef OP_IMPL_H +#define OP_IMPL_H 1 + +/* Per-counter configuration as set via oprofilefs. */ +struct op_counter_config { + unsigned long enabled; + unsigned long event; + unsigned long count; +}; + +/* System-wide configuration as set via oprofilefs. */ +struct op_system_config { + unsigned long enable_pal; + unsigned long enable_kernel; + unsigned long enable_user; +}; + +/* Cached values for the various performance monitoring registers. */ +struct op_register_config { + unsigned long enable; + unsigned long mux_select; + unsigned long proc_mode; + unsigned long freq; + unsigned long reset_values; + unsigned long need_reset; +}; + +/* Per-architecture configury and hooks. */ +struct op_axp_model { + void (*reg_setup) (struct op_register_config *, + struct op_counter_config *, + struct op_system_config *); + void (*cpu_setup) (void *); + void (*reset_ctr) (struct op_register_config *, unsigned long); + enum oprofile_cpu cpu; + unsigned char num_counters; + unsigned char can_set_proc_mode; +}; + +#endif diff -Nru a/arch/alpha/oprofile/op_model_ev4.c b/arch/alpha/oprofile/op_model_ev4.c --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/arch/alpha/oprofile/op_model_ev4.c Sun Dec 22 04:54:22 2002 @@ -0,0 +1,99 @@ +/** + * @file arch/alpha/oprofile/op_model_ev4.c + * + * @remark Copyright 2002 OProfile authors + * @remark Read the file COPYING + * + * @author Richard Henderson <rt...@tw...> + */ + +#include <linux/oprofile.h> +#include <linux/init.h> +#include <asm/system.h> + +#include "op_impl.h" + + +/* Compute all of the registers in preparation for enabling profiling. */ + +static void +ev4_reg_setup(struct op_register_config *reg, + struct op_counter_config *ctr, + struct op_system_config *sys) +{ + unsigned long ctl = 0, count, hilo; + + /* Select desired events. We've mapped the event numbers + such that they fit directly into the event selection fields. + + Note that there is no "off" setting. In both cases we select + the EXTERNAL event source, hoping that it'll be the lowest + frequency, and set the frequency counter to LOW. The interrupts + for these "disabled" counter overflows are ignored by the + interrupt handler. + + This is most irritating, becuase the hardware *can* enable and + disable the interrupts for these counters independently, but the + wrperfmon interface doesn't allow it. */ + + ctl |= (ctr[0].enabled ? ctr[0].event << 8 : 14 << 8); + ctl |= (ctr[1].enabled ? (ctr[1].event - 16) << 32 : 7ul << 32); + + /* EV4 can not read or write its counter registers. The only + thing one can do at all is see if you overflow and get an + interrupt. We can set the width of the counters, to some + extent. Take the interrupt count selected by the user, + map it onto one of the possible values, and write it back. */ + + count = ctr[0].count; + if (count <= 4096) + count = 4096, hilo = 1; + else + count = 65536, hilo = 0; + ctr[0].count = count; + ctl |= (ctr[0].enabled && hilo) << 3; + + count = ctr[1].count; + if (count <= 256) + count = 256, hilo = 1; + else + count = 4096, hilo = 0; + ctr[1].count = count; + ctl |= (ctr[1].enabled && hilo); + + reg->mux_select = ctl; + + /* Select performance monitoring options. */ + /* ??? Need to come up with some mechanism to trace only + selected processes. EV4 does not have a mechanism to + select kernel or user mode only. For now, enable always. */ + reg->proc_mode = 0; + + /* Frequency is folded into mux_select for EV4. */ + reg->freq = 0; + + /* See above regarding no writes. */ + reg->reset_values = 0; + reg->need_reset = 0; + +} + +/* Program all of the registers in preparation for enabling profiling. */ + +static void +ev4_cpu_setup(void *x) +{ + struct op_register_config *reg = x; + + wrperfmon(2, reg->mux_select); + wrperfmon(3, reg->proc_mode); +} + +struct op_axp_model op_model_ev4 = { + .reg_setup = ev4_reg_setup, + .cpu_setup = ev4_cpu_setup, + .reset_ctr = NULL, + .cpu = OPROFILE_CPU_AXP_EV4, + .num_counters = 2, + .can_set_proc_mode = 0, +}; diff -Nru a/arch/alpha/oprofile/op_model_ev5.c b/arch/alpha/oprofile/op_model_ev5.c --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/arch/alpha/oprofile/op_model_ev5.c Sun Dec 22 04:54:22 2002 @@ -0,0 +1,198 @@ +/** + * @file arch/alpha/oprofile/op_model_ev5.c + * + * @remark Copyright 2002 OProfile authors + * @remark Read the file COPYING + * + * @author Richard Henderson <rt...@tw...> + */ + +#include <linux/oprofile.h> +#include <linux/init.h> +#include <asm/system.h> + +#include "op_impl.h" + + +/* Compute all of the registers in preparation for enabling profiling. + + The 21164 (EV5) and 21164PC (PCA65) vary in the bit placement and + meaning of the "CBOX" events. Given that we don't care about meaning + at this point, arrange for the difference in bit placement to be + handled by common code. */ + +static void +common_reg_setup(struct op_register_config *reg, + struct op_counter_config *ctr, + struct op_system_config *sys, + int cbox1_ofs, int cbox2_ofs) +{ + int i, ctl, reset, need_reset; + + /* Select desired events. The event numbers are selected such + that they map directly into the event selection fields: + + PCSEL0: 0, 1 + PCSEL1: 24-39 + CBOX1: 40-47 + PCSEL2: 48-63 + CBOX2: 64-71 + + There are two special cases, in that CYCLES can be measured + on PCSEL[02], and SCACHE_WRITE can be measured on CBOX[12]. + These event numbers are canonicalizes to their first appearance. */ + + ctl = 0; + for (i = 0; i < 3; ++i) { + unsigned long event = ctr[i].event; + if (!ctr[i].enabled) + continue; + + /* Remap the duplicate events, as described above. */ + if (i == 2) { + if (event == 0) + event = 12+48; + else if (event == 2+41) + event = 4+65; + } + + /* Convert the event numbers onto mux_select bit mask. */ + if (event < 2) + ctl |= event << 31; + else if (event < 24) + /* error */; + else if (event < 40) + ctl |= (event - 24) << 4; + else if (event < 48) + ctl |= (event - 40) << cbox1_ofs | 15 << 4; + else if (event < 64) + ctl |= event - 48; + else if (event < 72) + ctl |= (event - 64) << cbox2_ofs | 15; + } + reg->mux_select = ctl; + + /* Select processor mode. */ + /* ??? Need to come up with some mechanism to trace only selected + processes. For now select from pal, kernel and user mode. */ + ctl = 0; + ctl |= !sys->enable_pal << 9; + ctl |= !sys->enable_kernel << 8; + ctl |= !sys->enable_user << 30; + reg->proc_mode = ctl; + + /* Select interrupt frequencies. Take the interrupt count selected + by the user, and map it onto one of the possible counter widths. + If the user value is in between, compute a value to which the + counter is reset at each interrupt. */ + + ctl = reset = need_reset = 0; + for (i = 0; i < 3; ++i) { + unsigned long max, hilo, count = ctr[i].count; + if (!ctr[i].enabled) + continue; + + if (count <= 256) + count = 256, hilo = 3, max = 256; + else { + max = (i == 2 ? 16384 : 65536); + hilo = 2; + if (count > max) + count = max; + } + ctr[i].count = count; + + ctl |= hilo << (8 - i*2); + reset |= (max - count) << (48 - 16*i); + if (count != max) + need_reset |= 1 << i; + } + reg->freq = ctl; + reg->reset_values = reset; + reg->need_reset = need_reset; +} + +static void +ev5_reg_setup(struct op_register_config *reg, + struct op_counter_config *ctr, + struct op_system_config *sys) +{ + common_reg_setup(reg, ctr, sys, 19, 22); +} + +static void +pca56_reg_setup(struct op_register_config *reg, + struct op_counter_config *ctr, + struct op_system_config *sys) +{ + common_reg_setup(reg, ctr, sys, 8, 11); +} + +/* Program all of the registers in preparation for enabling profiling. */ + +static void +ev5_cpu_setup (void *x) +{ + struct op_register_config *reg = x; + + wrperfmon(2, reg->mux_select); + wrperfmon(3, reg->proc_mode); + wrperfmon(4, reg->freq); + wrperfmon(6, reg->reset_values); +} + +/* CTR is a counter for which the user has requested an interrupt count + in between one of the widths selectable in hardware. Reset the count + for CTR to the value stored in REG->RESET_VALUES. + + For EV5, this means disabling profiling, reading the current values, + masking in the value for the desired register, writing, then turning + profiling back on. + + This can be streamlined if profiling is only enabled for user mode. + In that case we know that the counters are not currently incrementing + (due to being in kernel mode). */ + +static void +ev5_reset_ctr(struct op_register_config *reg, unsigned long ctr) +{ + unsigned long values, mask, not_pk, reset_values; + + mask = (ctr == 0 ? 0xfffful << 48 + : ctr == 1 ? 0xfffful << 32 + : 0x3fff << 16); + + not_pk = 1 << 9 | 1 << 8; + + reset_values = reg->reset_values; + + if ((reg->proc_mode & not_pk) == not_pk) { + values = wrperfmon(5, 0); + values = (reset_values & mask) | (values & ~mask & -2); + wrperfmon(6, values); + } else { + wrperfmon(0, -1); + values = wrperfmon(5, 0); + values = (reset_values & mask) | (values & ~mask & -2); + wrperfmon(6, values); + wrperfmon(1, reg->enable); + } +} + +struct op_axp_model op_model_ev5 = { + .reg_setup = ev5_reg_setup, + .cpu_setup = ev5_cpu_setup, + .reset_ctr = ev5_reset_ctr, + .cpu = OPROFILE_CPU_AXP_EV5, + .num_counters = 3, + .can_set_proc_mode = 1, +}; + +struct op_axp_model op_model_pca56 = { + .reg_setup = pca56_reg_setup, + .cpu_setup = ev5_cpu_setup, + .reset_ctr = ev5_reset_ctr, + .cpu = OPROFILE_CPU_AXP_PCA56, + .num_counters = 3, + .can_set_proc_mode = 1, +}; diff -Nru a/arch/alpha/oprofile/op_model_ev6.c b/arch/alpha/oprofile/op_model_ev6.c --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/arch/alpha/oprofile/op_model_ev6.c Sun Dec 22 04:54:22 2002 @@ -0,0 +1,91 @@ +/** + * @file arch/alpha/oprofile/op_model_ev6.c + * + * @remark Copyright 2002 OProfile authors + * @remark Read the file COPYING + * + * @author Richard Henderson <rt...@tw...> + */ + +#include <linux/oprofile.h> +#include <linux/init.h> +#include <asm/system.h> + +#include "op_impl.h" + + +/* Compute all of the registers in preparation for enabling profiling. */ + +static void +ev6_reg_setup(struct op_register_config *reg, + struct op_counter_config *ctr, + struct op_system_config *sys) +{ + unsigned long ctl, reset, need_reset, i; + + /* Select desired events. We've mapped the event numbers + such that they fit directly into the event selection fields. */ + ctl = 0; + if (ctr[0].enabled && ctr[0].event) + ctl |= (ctr[0].event & 1) << 4; + if (ctr[1].enabled) + ctl |= (ctr[1].event - 2) & 15; + reg->mux_select = ctl; + + /* Select logging options. */ + /* ??? Need to come up with some mechanism to trace only + selected processes. EV6 does not have a mechanism to + select kernel or user mode only. For now, enable always. */ + reg->proc_mode = 1; + + /* EV6 cannot change the width of the counters as with the + other implementations. But fortunately, we can write to + the counters and set the value such that it will overflow + at the right time. */ + reset = need_reset = 0; + for (i = 0; i < 2; ++i) { + unsigned long count = ctr[i].count; + if (!ctr[i].enabled) + continue; + + if (count > 0x100000) + count = 0x100000; + ctr[i].count = count; + reset |= (0x100000 - count) << (i ? 6 : 28); + if (count != 0x100000) + need_reset |= 1 << i; + } + reg->reset_values = reset; + reg->need_reset = need_reset; +} + +/* Program all of the registers in preparation for enabling profiling. */ + +static void +ev6_cpu_setup (void *x) +{ + struct op_register_config *reg = x; + + wrperfmon(2, reg->mux_select); + wrperfmon(3, reg->proc_mode); + wrperfmon(6, reg->reset_values | 3); +} + +/* CTR is a counter for which the user has requested an interrupt count + in between one of the widths selectable in hardware. Reset the count + for CTR to the value stored in REG->RESET_VALUES. */ + +static void +ev6_reset_ctr(struct op_register_config *reg, unsigned long ctr) +{ + wrperfmon(6, reg->reset_values | (1 << ctr)); +} + +struct op_axp_model op_model_ev6 = { + .reg_setup = ev6_reg_setup, + .cpu_setup = ev6_cpu_setup, + .reset_ctr = ev6_reset_ctr, + .cpu = OPROFILE_CPU_AXP_EV6, + .num_counters = 2, + .can_set_proc_mode = 0, +}; diff -Nru a/drivers/oprofile/oprofile_stats.c b/drivers/oprofile/oprofile_stats.c --- a/drivers/oprofile/oprofile_stats.c Sun Dec 22 04:54:22 2002 +++ b/drivers/oprofile/oprofile_stats.c Sun Dec 22 04:54:22 2002 @@ -9,6 +9,7 @@ #include <linux/oprofile.h> #include <linux/smp.h> +#include <linux/threads.h> #include "oprofile_stats.h" #include "cpu_buffer.h" diff -Nru a/include/linux/oprofile.h b/include/linux/oprofile.h --- a/include/linux/oprofile.h Sun Dec 22 04:54:22 2002 +++ b/include/linux/oprofile.h Sun Dec 22 04:54:22 2002 @@ -26,7 +26,17 @@ OPROFILE_CPU_PII, OPROFILE_CPU_PIII, OPROFILE_CPU_ATHLON, - OPROFILE_CPU_TIMER + OPROFILE_CPU_TIMER, + OPROFILE_CPU_RTC, + OPROFILE_CPU_P4, + OPROFILE_CPU_IA64, + OPROFILE_CPU_IA64_1, + OPROFILE_CPU_IA64_2, + OPROFILE_CPU_HAMMER, + OPROFILE_CPU_AXP_EV4, + OPROFILE_CPU_AXP_EV5, + OPROFILE_CPU_AXP_PCA56, + OPROFILE_CPU_AXP_EV6, }; /* Operations structure to be filled in */ =================================================================== This BitKeeper patch contains the following changesets: + ## Wrapped with gzip_uu ## begin 664 bkpatch23217 M'XL(`/ZU!3X``^Q<_7?:1K/^&?Z*K?N>%#N`]<F'';MUB9/XQG%\<-JF)\WA M+-)B=`V2*@G;]-+__<[LAR008$SBO._MN6F;FOV8G9V=G7V>V<7?DU]B%AV4 MHF18_IZ\">+DH.0&49`,I_5XT*?3>L3<(4WJ3C"&!MT@@`;[LL4^]-H?>?[D M?C\(:T;=+D.32YHX0W++HOB@I-?-M"29ANR@U#U]_<OY2;=</CHBG2'UK]D5 M2\C143D)HELZ<N.?:#(<!7X]B:@?CUE"<>19VG1F:)H!_]AZT]3LQDQO:%9S MYNBNKE-+9ZYF6*V&50;%?EHUC05ANF'`?Q:(G)EFT[3++XE>;YMMHAG[NK%O M&$2S#FSS0&O7M-:!II%ULLESW2`UK?PS^;KSZ90=\NG]9??]J[/ST\_DE1?% M"7$F":$)"<(H&'@C1N))&`910@9!1$Y&X9#6RV^)KFNF4;[,C%VN/?)/N:Q1 MK7S\P(QHY`SW*8ZZ_X[>,%0H-S<+[#S3[;9ASZBKN^V6Z[C-09M9%EUKSY5B MQ:K9IJ;/M!;\`_J-V&W@_S0.;MF8^0F-/.K7@^CZD]+[\\SSG='$9:G+"KO5 MAT*B!K;781&LF6Y9MCZS'=O63<=MPP0LJJ]?^`=DY[0U6DT3M-UTUDH2_-`; M!RX;]=BM77?FQ9HS4+[5GMG]9HNUV,!RC;;3MAY0^;&C6/!1;[>_4/E&47G3 M;C1M4%XWC:;3I(W^@+K&UQW$FFEFJ[&5X=\Z@3_PKA<7TC0,RYZ!K0>P;P>F MH\%???TKB3=F$)"L!JC[EQ>&;/03=ZO:N-&Z6?#IG,@Y29JI:99IZ*V9UC;M MULQUX.^^PYQVW[(><N950K/9VU;+UA\3%&Y8Y+/1OA?]V>,%<H'2\&"`"]MF M:];N-ZCMZAJUF$4A_FVLZ(H!YK:>96_E`2LCCV:W6S.J4]-MF&VJ6^!CYN8! M[0'YQ@P\5F]MHS"4CV$QG$6!&GPT9X/&@+G4U09NLV7#>?.UY)LS`^:_62AV M(P\A0G[SBA]Z<4*36(G.Q60($NV90UW39*[ANI1:S?9ZS3<<([>E[::F;1G> MO'$X6HSVL(*6U6[.F&.YFMTTJ,NL08LUO]H`$#J;S4;S"R.RM<113-NT9GUF MZ(PU&T;?;K==;3N]5XX"[M(V6@T.!1]<*H2(W\JKOOY`""T-N\FAI5$`EOIF MP/*I<.690"[DA8`NR3!BU(WKPV,.)"^ZO<[E+U<()<7V>$]JT1W_%Z#AY<,K MMP7>/--UHI>_]U8IQEUF%>#:S%.^#`I^\0"&WC9,'<Z/F6V:ML$=P]S6,<`S M]"?QC*NI[Q`GG!!_,N[#(I,[+QEF?,.YC0\)=5W"-[UJA)[",>Z"HZPRR!;^ M\=)H@W^<X=]ZN:1H$?II[\/9N]-N=:&P^Z&S6'1I+9:<G326EO7TI:7&8NF; MDW=+AC[Y>-D[_;4@6!3;RXHO.R=V8WE[*$;/7X,BT?DOV!W!LH-U#<N_$JN\ MGB9_,1;F7JUMZ=7:4X0[A_SL)6\9"UG$34169C+VU]D.0B%.&)QZ7:LN*1CD M(]'N6X:^A<M_BZ72MUPJPWR:H^D5;/*W1!"AA6"RSNZ/-^Z91@RS_$<98OF$ M[%QR>9Y_K1(J.^62"R[CNS$)?'+Z\?*T"U'FXL/).?21^TYLUK.+U^52/PA& M2Z202K[G+@@=LE%8+A%R1:?D=S)D$0,3$N;3/GAF,F2$W2<P*G-)6!`V9@[8 MTXO',9G$S$4Q_:ELAY$ZGCA#0F/R_E+&66R1J:N"2[F41!X>U(SLJ*8DGL8) M&^<&+6B>,T=NXFH^J2`O)C2ONY#KT)#/,!CDZF"ZV/5N&*0*5-61P6TAZ%U5 M_I\`JIR,6%PE(Z\?P?D+/V)_ZL-I%(8CSZ&)%_AP&/V!Q6<#,O'C2<2J)`9C M7V`Q3`#7&WY:%5,5+7LXJ*J66T;5Q_'+?UQ83:WWEL!\5^SNM%&7%`SR+</J M%FNU;5S5K:>,JR*YL$%<32V_56#5K7+0_^_:ORJ=]Q>OSE[W5.39)<^/4BA9 M#V`;ONR>_7K:[;W_^;^NR!'Y5P6091C!R/>D7M\7_Q;(1I7`_B[QC_4`H6JO M/QD,6`0?Q`^]&#`L?,)F[!:P>M8@)2KX5RS;J,)!G&\AJ$Q`=D%-55B;EN#/ M`6J:TWR7R-Q(D#5,YWYR?OGFI/?Z]`*":6>WQ`V0X\="`_A#")G+PZZH:*P9 M!##G;JDXPIKV=J&]O;9]H]`>]5D52U7&Z.%8JEIN&4L?E_I:$4N-_[.Q-+7> M6X0TRS=TVJ9+"O;XEJ%TBZ4JAM+-EDIOMI\REHJ\YP:Q-#7]=K&TV2[O[^V5 MR1[YB?O&VB&(:!BQ,8UN2"<(IY%W/4P(3BW#:'22#(,HSC?M,NIRS,4;=-Y? M_H[P3HH3[4G7`_P9N>0-`M0H!B#X`E<@N?-<%^*YSY)C:+X/\7(QC9,Q_^-" MG>=[R;+R>!PN*V91Y`?S%30>[X>PJ`XKE@M8B>4YK7;2U.H.@D)`W)%/XB2: M.'BSVJ/W,K[-!5+2Z]$$D'-_DK!>KU*Y8_1F=_=PP^[VEW0/'6HWOFS\E=W_ M*.-!YSE+!>SQ_QUF1KH-/)=4]B!0#7I>].=N!2"V=^T#78&-=5U50L*D%['K MF.S!`%*\[!G36]9[3/<E^CG!Q`=M>I+7.$GTR?Q\6&PGUEXU@T]+VL`XP(4R M8?`9Q]S?(QTZ&H%B@PABB1OT`$:<^0F2-8@7KB1K.)$@&E/?8<!.P)%AEWBH M6S0)DSH1FR%G`#A:>Z)[+VTV;P-@0[#+BI;`OW?+_U,N@69PS@.A\G](D$N! M"J,I<;V8\RMIFABT<+U;SYW`)*:<!Y*77NS@[MV1;=T=PL%13/S@3NA:\@:D M\AW:DVOQN2YXJ;L+2"1BR23RT3:H0I<Y020"1DQA)S$I($5/`.1ZHJ:"JM>. M0Z>:SFT<]J"=P^(XB'J>6Q%^B'*!M*%,H+<1V!DH+1LQ)P';4#\S+*P)^W/" M?&<*C6D"E)-/T`\28,_42493+@3"$F8NA41I&-`A\H#X4N(#((%38<(I*,H. M\NT$EQ;2DQ]&L)4`@PY&P1VA`ZR^@.6.1%=AQ)P!<<(0#)D+2Q>SA!P?BXGO MDF=$1U/R354[YK4]L';E&?20U@%+_%TFRF=`K;+<D-!V$E;0B;@;S#N-5R4L M-:$/G5'C2<X7I=-&V439/?@]LO!A$-Q([><V)^!Q]>-AN90K7>+#:NQ.,`XA MOO`!QC2^0>M+'TI=4XZ%]PP5#\0!U2;:(?'("R(-XT_&:H_'A^3Y<P^-AI9% MS]3FO++$R.R(Z.3%"^*!EFAYF4LYRBQR&;&:D].,+WN,6SE.@!B`37@QGFUW M-&)$Q02E:KI>UW(5Q'J!-E7R#,+*;C9]C"&32`R3BL&4":X(4!4E$K>``V6] MP<1W,&M1D8,@G>&#@&@^BE8%ISE,E4CKN1*[?,ZX,<&$X#B%8,,]9SA)W.#. MSYR';V"\R%CN)*#C;[A^4]+'64!#D:WQ8IF"D9/(^<2<YZS4A"N?T"CAJI`] M=S(>3[E&=Q%VAA!:T:LD6\7=.5'YW9!*X=V+YEP<L4HN?CD_S\Q9T`BK5YK3 M\P%\L"5S"<+"5,"X+V4T7G(\H"71];D_S.^(S`:@9$W?7;V@:MA-YAZ$:Z<. MDN3,EQO:B1A-)%VNR$,IGH"BO?XH<&X`'<;]]+1R(1)&4RB+@B#ARH$DW)A_ MY/;[0WN=0+?2@D#7BT#Q$L)/Y/B?C,]<9@E_UCZ#4(\\)S]H/QS*,OTS'P@^ M04^2Y1P&<6]\`T455!J5K*(XL7]S:0`UZPD&5]X6^E3)C@P\.[`W,11Y62@Z M+).%/QM(PX,C+PL_XP)MH`DW6:XO_XQ]<15YK%3Q@OH8+_AYRT&=L.^Z$81= MY&1[(1WM5$4F`F-=/2M^4-5Y02*)NTR6J'FD.(0(RX1A>6J(I9LY!7\2JB"$ M$IEC4<;]/@AC\!LP53V_`TI'9,F^`"WJ/":7LGH1P[%"1M]<E2SAM1A[\MUX MK.(5P9PX^%C^&_T4=U2OAZ2IG($MH(2\J+)F;GM[,"?`";#CLGJ\Z-V#OT0D MN?/PT6X%J1'`'8!E:`"'QHR<O;L\QW070,\#A6#`/L_R!(EO/C#+S6&ADXV= M(#`:NMZP+CL<VE$2CY";<O2*Z3GP?H)X"3&#P%1EGOU"K'GM>W^)4]49>B%> M>W#XC1`*@ZL$>>]./D+LBGT5406>I8A$*B?O3J[>]J#%+L<-Q1EPDH5S8*.8 M+6\"-&[-)!NK+-/(=W+9@$Y&2;XM!N#\UOV.5V2@FYQ>O']Y^BN/4GO",9_- M>2ITQD6$\@PE+!QEJW)T*1-^.$F7-MTR2_?(!U/_N#1=9K^WA$]Y1;XH:]<E M!:-\RUS=-@NV;;+.>M)<G7@QMT&N+K/]5LDZ:X-<73;$?TRR;@!-!C!B#X-9 M[TWY>_B(>#<M`2/RG,@EBVJ*(3N2[/#CA7"NGI!;C^:0CPC#*Q,W!1HKT=1A MH1R/@T(IEW8H3D70[8IG>VHP/[:-;O/)HA6J(>PI:I=',:MJ$99DNG:H,X0& MDH@B-!:\-/*"2;R*-BS0TM4YK!7*%U0;3^Y[(L%2J$KA8J$&<R^%0I'*$-,I M5&:ID,P`Z$BX.;P$1D?"K%9LRJ_S,2=1F&:6EH0)RG1BRLEW266U0?8X3@0H ML=(5E[28=PA,1:I!4PX.@PKVEZM,LSH/:$3FC(0"BLA,'.-I0TY_Y@C38F4! M[4N+?P]!P!NL`P&Y%[L;(8%<^^WAP*,?(_\3,4'>DOC>UK16GTWYMEU2L,XW M!@?;+=^V"*']M+=Y_%GZ9@@AOPI;P83V9C`A/\Y_#%;XDHN]#2_DQ!$I$[8\ ME3U82*AZ/G*_D,H#'@]0?L9YXN@2[\N6W;^`,7M9'G=-?,;<*T_OKSTU,`5< M;+5P<F"&N)BR=Q*D?EI5P)@J&7JC0.61K_BA3%P6>[`#LAN&W]@/MYB8#4,F MUI37J$?87)'LW@+JI[#H"6:,&+\4R7+_MX)KXRC<?AZ##27?S9&+@.?)A8B( MO^CS`UBBP6`'<50B3'OFDS[L5((D."9W3(KC$G",TX\?3KL7)^=JL&`2.0RF M&80BF9S>K/0%KQ\%=RP6W=/KG2H'`XC=N`.GMSX*@L)TSM__!LI\@.HTC2T, M(4$5,/3<A9?JJ&YS8H+Y?EB5`.TLL@KJ/F@A)RZ-\P&SX#P1'L,$HLA#Y\*K MRSYS)I@/F+M)V(,#>4^][@1!7(2ZJTOFE,XIG+_$XX\NP8"C*:8JDU3!-%DL M1`PH8$4W8#'>"L*6">[`NFH#E-#79D>+]R?D1Z(*^!*]>$%:Y(#H%O\)$4F^ MGY[OEY;PCC6B-W:QDVE`_^9D)'Y.KT7D?26_H,.O<Q"8J;B&\V#>:DWR\!;7 M,_!'4^E-Z#$!\!$4X@;X_6>,"A[">I`Q(--@DKN@`Y>Y!I>A_OQ*BEL-%*$< M:MD%85SE]T+!6%[NX6M<[/J!WBRLF.B1W5#*G!0"?1$38)_"!$%Q$(C:RX'" M((X]7'\!EX6/*W.0/G5NLG7C(QRI99*$1UR%\:H71\32V@U,%:FV^%E$$_B@ M(ZP4Z2Q5W[!M,VN@\57.I.-@<I053O/L&>\KUOMP44M]A9:&/:<D?%RGX]P< ME(KZ>A7UHHJ'(@5\73O.F`[7<[00:%<0KB`4[XE%,A&:__CCC^2"8>P-\,D? M+'8HOAZ#_I(]S\9J_APE\^'42^2]-T.IN"]PS_*-,:2W>"V=%Y+KJ9Y`P\[A M=^,(#;AT$/,*"OW@KIK&F=$=G2JM^?13.B#,*>;^*@VG'@:?$;XYYR=$SE@8 MDT#+O"R,PGDQ5[`%:1_O$J$:XAX:#HX+[M!S2N0YHEQ67IZ[*9=B_Y8<,0JN M(SI^`@207:(*^G8OTM]KT0`H=\_GG%W3&?RJ,N]=S>E/69W<OZA[B@9=& MXN(AQ2EX#S`'7/""()V#JLUNCGE?R4*QEE__B2XE_+SBRTKU/+7$=@;OM$@I M2XA:D%9NP";M1[))^VNPR8U_4\(*-FG^$]BDS=DD3OMA'F-S-EFPSK^)33YN M^8IL<K/ET]NM)Z63_)=F/(Y.VEL_$6VW'L4G[?_GDUN=)B"("&S*[S%)!1_0 M<_BF[C4KEYV3!I3=TFBJGA7U`=6%(T`#^*UA3@(0&S(XY!%B"$UV.C^__[B3 M$;W7'OPD2-(=XGI$]0X2"CAI)XGJC8(X2X,#/`P\9)$TBM!ATY2RNEEU$+@N MJ`)'?9^A#$%Q.((5#XGA?RY;=GB*ZL<PZ-*#[+FTECGS!GCG[?2#>[T7#.)J M^M'`C]DS$WR1-:J*7'1U+NN\GE5_6"32G!2FB`T9M>0ABE4CLM^451_PMR67 MG:O3<^V@A&]PU$?]H&18-;.-,\3UUP\`^-:LIJHWX'.KUC!5/7QN6+6FGC)1 M).>H:G('C"5DCD='@HY7A>^!NIW?.^>G5YSU]!&A4OQ"G*"A^#T^'.:39GP6 M).2J<])Y<]K[K7OVX72Q"S9')3[IQN>Z&C]>9CCH"!#:H2/O+_'(#FSCX7&& MO[X*4Q>PR\`?Y\BI@(.+3X3,W(.@)1="DG*HES.'ZKY_X6D.)O;!H8"E3\2+ M0/G\#=:0[Y")^.:@G`KRL1A]Q(F\/KX[16B;?TX`^@$R$DKQ`JD+:,V'*BG= M=..YU3KD;Q2!W9"YIE"ES[>VGC?XVX*_E8:=P`=&FQ33/()0YD`Z[FI\XI#7 M4C)Z4)1/7_"DE.:;NGKG0.8:6[PU#`X,%]9B;W]I,TO+"ZVH'`#T1MG6\CZM MI7U`%/9)]S:9$=U>+:5A%:<#0EI+&S>-I4,VK'1((QV2O[[8C"JJ=\N<@GTA M-4R##-]0>6HH.9UB?_P1>DBSK\+B=DV)H-0BVTARSM]!_*P=9S>7.._VBFHI M%S,_*UKPX=!Y4N:6IY5%2Q6?:WM\:@]F4K@Q\MD4/MN'LBDJC<23.K$(4?G7 MY)QX(M7%<Y`E=XSYF'N5H$!6@VS^"CM-LRFIT$]05(BIC$*#PBM_:7Y%9!=9 M[2."VYC>B^2'S`UG<4[E/3:,<\LR,$M3,$!485!1F.XE'N!$L0QZY$<@%&;+ M(@<BB\1?[)6D#.-0!40QPC&*%#%.#0D%(L252OD)90F=/\KI?N52P=LJ`-.) MMV?PL80]<3>C7C71C6_GBM7B:<@];_=P;N;?':5ZY)8D_V;\[_G$!G?DI1D+ M"2:69"WF;K@+^0;[WW;C4(!KV;MUA%9`'*K$,)8\-.9OX1ZO]J:*?P756Z"] M>B+]A+DB.TNKD&^?+,I56[(:O72^IB%K\MZ:&:;SH2M^)8.*9#C[-,9E7[3A M(3HN?-.&]RKS-+J*FOGH*X*MC-P\^0CMU.U''9]NJEQ[*@C'1Z4D:!9Q-T[X M!0QT[IZ^KAUW3Z]./_1^/3G_Y?1*LJY7/!-I5^77$(``Q?(B96X5J_R"0?YR M">),(OZJ5&;:.?$"H(35DIR)X5.V)*F!6E+Q;2$N%JJAQR12O"O[+1:8L0>; MI.P0U)/8&7R$T3%^<\!%9))U\6)Q_*N$]2"?UJVCF#.)W_D34Z"`-P@&%`') M+H@0;V/R6$Z4LQ$GXO1.ZEEQQ;'69W+6V>_28+NK?#[[9M(#&Y\LWFE&2VXZ MU3T'FKZ*ZO;"F^K"DR'8*OS[0B*9S]$TG#;:_0#^B/LDJY5%CP,B&^D+C4P# M`OT!%)E0A`5Z0]P"B%&)#/MM!'T2Z_`K@H4XO[";#M7#W,H"['DF9[.+NJ@? M\=Q,967;%%Q7XV?3_[9W-KUMPF`</Y=/@7JHB%H2',`$59O::9/60Z4=UO.4 M$I2PA%"5H$E3M\\^OQ(,=F)(2*MJ.>1`>/,+V,\O?_^?\C=+N.X%J9\!NC.K MW/*7U,F%:=/A3WCFRP?][(]9CM?-)20GOI?&0AX^?:22?`WZ[<OIM[^3?OL[ MZ+?0H?=@<%^&P5T5!@=75%VEL7974J;:&-M;J;BW6-MR:>!]V!+OPV/@?5TO MX?=,]R'3BJ%B[^?*D.%]L79>B>ZW:KVN<#_LR3>S--%I&!UJ-$$GM!^"5F0? M_B?[QYO[=PB`^E**2:CV%5M7^7IRL3IU:J[0QDJ,JL1HL(WO+4%ZA!?&<^S' M3P,$M%&7>G#H2!;5^]=Z\&Z5S>>G$7;`TPL[P%9N!7$$0N("\HI3BYTPZR;E MY+PKPY(_$S]@U.26U].G@HA!-L5ZNHFQ%NT7E5)1W1(KD7CFBG*/!7D52P5T MU8JI`CF:Q3;T9;5)TK@LJ"91&RN)VK$PVD<T9@('?P24QC=>*\%6%5WQO45^ ME:!(!J+`9CQI`BSAHGLH5F=FU2-$@6\%HLA0"0IRW/>$2Y1#V6$A_=Y*M$A7 MQ+OKJ9RD,9$PZ$HB(K@S(H+:<9XT'FHG=ZH:A?:4)<=83I.;S1,8/A>+9[M8 M)_9C%BV*=#B+U3ER`#HI="9.^.*XH0?I/+J9V$C/C=(S;;<7E_';V:R1PPB; MB).T/NJY]0&VE)]#WW2-NS!`\6>$'A]JY7@IM"E+)U+=E*8CNGOIA7A_^_WK ME_N'0?W@%%6.':?%R&".E1+_R]HAY13>6"6/N>R.T/91O><UDYZTZH-=D[)H MAWVJI"RH9SK`F?@>3LH2,/E69Y_4OOSOOTWSG/EJH4J?%UPJP\UMB-4]SBFC M[J7-"NC27X,`^]V3[[/2:L=:37\\X3]!B!]8XZ54<83O*8>0\3-/\#\S^<TR M^YUF0VN-QK>!\FP`A*A33<;ABP\\CT;UP5M+AJ%Z&=%\1^IV/L!\//0\U*YT B48QYOL/9_'R;7B]:Q-$R+](/,^C%KA]%QC\$70!%R6\````` ` end |
From: Richard H. <rt...@tw...> - 2002-12-22 08:30:09
|
On Sun, Dec 22, 2002 at 01:48:02AM +0000, John Levon wrote: > Are you referring to the event number field in libop/op_events.c here ? Yes. > I'm a bit confused by your comments. This number is the actual value > that must be written into the perfctr programmable registers as defined > in the Intel manuals. Is there some reason you're not doing the same for > Alpha ? (1) There is typically one register that controls all of the counters. It's all encoded into a 64-bit value. I suppose one could take the view that this number should be the value placed into the field for that counter, but: (2) Several events can be put onto more than one counter. However, the values placed into their respective fields are *never* the same. (3) It makes the most sense to me that the CYCLES event is seen by the userland tool that interprets the event stream identically, no matter from which counter it originated. Now, as it happens, I have *some* method to the selection of values to place in that field, e.g. from ev5_cpu_setup, /* Select desired events. The event numbers are selected such that they map directly into the event selection fields: PCSEL0: 0, 1 PCSEL1: 24-39 CBOX1: 40-47 PCSEL2: 48-63 CBOX2: 64-71 There are two special cases, in that CYCLES can be measured on PCSEL[02], and SCACHE_WRITE can be measured on CBOX[12]. These event numbers are canonicalized to their first appearance. */ ctl = 0; for (i = 0; i < 3; ++i) { unsigned long event = counter_config[i].event; if (!counter_config[i].enabled) continue; /* Remap the duplicate events, as described above. */ if (i == 2) { if (event == 0) event = 12+48; else if (event == 2+41) event = 4+65; } /* Convert the event numbers onto mux_select bit mask. */ if (event < 2) ctl |= event << 31; else if (event < 24) /* error */; else if (event < 40) ctl |= (event - 24) << 4; else if (event < 48) ctl |= (event - 40) << 19 | 15 << 4; else if (event < 64) ctl |= event - 48; else if (event < 72) ctl |= (event - 64) << 22 | 15; } wrperfmon(2, ctl); which means that the SPLIT_ISSUE_CYCLES event, which is obtained only on counter 1 by PCSEL1 field value 1, is described as { 2, OP_EV5, 1+24, &um_empty, "SPLIT_ISSUE_CYCLES", "Some but not all issuable instructions issued", 256 }, and CYCLES, which is obtained on counters 0 and 2, as mentioned above, is described as { 5, OP_EV5, 0, &um_empty, "CYCLES", "Total cycles", 256 }, (I've yet to figure out what op_unit_mask actually does. I suppose I'll have to read the x86 docs to figure it out.) > I assume you've defined an op_cpu_type for Alpha and are adding the > events to op_events.c. Three cpu types (ev4, ev5, ev6), but yes. r~ |
From: John L. <le...@mo...> - 2002-12-22 01:52:09
|
On Sat, Dec 21, 2002 at 03:28:40PM -0800, Richard Henderson wrote: > No, you misunderstand. I'm not suggesting that we try to force-map > all cpu's events onto one other, just that we have a taxonomy. This would probably be useful at some point as more archs get supported. > I actually menat wrt event numbers. I've started choosing > them as seems conveniant for the architecture. Are you referring to the event number field in libop/op_events.c here ? I'm a bit confused by your comments. This number is the actual value that must be written into the perfctr programmable registers as defined in the Intel manuals. Is there some reason you're not doing the same for Alpha ? I assume you've defined an op_cpu_type for Alpha and are adding the events to op_events.c. Is this currently too inflexible ? Are you doing something different ? I admit I've yet to read the Alpha PDF's I have ... regards john -- "ALL television is children's television." - Richard Adler |
From: Richard H. <rt...@tw...> - 2002-12-21 23:29:31
|
On Sat, Dec 21, 2002 at 11:50:35PM +0000, Philippe Elie wrote: > > Obvious stuff like cycles and cache misses should be easy. > > not so easy e.g. AMD Athlon don't get a cpu cycle > count (the most near equivalent is retired insn). No, you misunderstand. I'm not suggesting that we try to force-map all cpu's events onto one other, just that we have a taxonomy. > > Suggestions on what I should do with my events in the mean time? > > Use documentation events names please unless you > think they are really confusing. Anyway later we > can add some synthetic events mapped on real events > available for all architecture. I actually menat wrt event numbers. I've started choosing them as seems conveniant for the architecture. r~ |
From: Philippe E. <ph...@wa...> - 2002-12-21 22:53:49
|
Richard Henderson wrote: > On Sat, Dec 21, 2002 at 02:16:30AM +0000, John Levon wrote: > [defining independant architecture events] > > >>... I'm a bit nervous of trying to draw >>parallels between counters across architectures. > > > Obvious stuff like cycles and cache misses should be easy. not so easy e.g. AMD Athlon don't get a cpu cycle count (the most near equivalent is retired insn). Beside that using the documentation events names easier a lot code review and allow for user to "grep" HW manufacter documentation to get further information. > > Suggestions on what I should do with my events in the mean time? Use documentation events names please unless you think they are really confusing. Anyway later we can add some synthetic events mapped on real events available for all architecture. >>This is not true. oprofile cvs matches the current kernel. What you're >>probably seeing is that the old startup script (i.e. op_start) for 2.5 >>is currently installed as "op_start_25" instead of "op_start". humm I stopped looking in 2.5 from the module breakage in 2.5 (49/50) ? The last thing I do on 2.5 is separation of module samples for each task. I'm guessing it will work ;) regards, Philipe Elie |
From: John L. <le...@mo...> - 2002-12-21 21:18:39
|
On Wed, Dec 18, 2002 at 12:14:38AM +0000, Philippe Elie wrote: > John, what about adding a sysctl only readable in 2.4 module > abi_version ? Daemon can also check abi_version and bail out > if something is wrong. It will help prospect (absence of sysctl > means older version) and also us cause it's a common error to I can't say I like the idea to be honest... regards john -- "ALL television is children's television." - Richard Adler |
From: John L. <le...@mo...> - 2002-12-21 14:09:10
|
On Sat, Dec 21, 2002 at 12:38:27AM -0800, Richard Henderson wrote: > No, I hadn't even noticed anything wrt op_start. What I noticed > was the missing p4 support in the 2.5-bk tree. Oh, sorry, yeah (this is what happens when you respond to email after coming back from the pub). As Graydon explained, we still need to forward-port their side port to the backport of this stuff ... regards john -- "ALL television is children's television." - Richard Adler |
From: Richard H. <rt...@tw...> - 2002-12-21 08:38:43
|
On Sat, Dec 21, 2002 at 02:16:30AM +0000, John Levon wrote: > Which numbers are you referring to ? The event numbers are not random. They aren't? Oh, well, that's not obvious then. Especially given the apparent lack of symbolic names for them. Perhaps I'm missing something? > ... I'm a bit nervous of trying to draw > parallels between counters across architectures. Obvious stuff like cycles and cache misses should be easy. Suggestions on what I should do with my events in the mean time? > This is not true. oprofile cvs matches the current kernel. What you're > probably seeing is that the old startup script (i.e. op_start) for 2.5 > is currently installed as "op_start_25" instead of "op_start". No, I hadn't even noticed anything wrt op_start. What I noticed was the missing p4 support in the 2.5-bk tree. r~ |
From: graydon h. <gr...@re...> - 2002-12-21 04:08:43
|
On Fri, 2002-12-20 at 18:53, Richard Henderson wrote: > Alpha has the ability to enable performance counters on a per-process > basis. I.e. enabled and disabled during the context switch between > user/kernel *and* based on a bit in the process' task control block. > Is there any way to use this with oprofile? If not, I can leave it > running all the time, or only in particular protection levels, so it's > not a bit deal, but it seems very useful. iirc the ppc hardware can do this too; it's a bit which marks a process for profiling, meant to be propagated between parents and children by the OS, and the counter control regs have some corresponding bits saying whether you're counting the marked, the unmarked, or all the processes in the system. the ppc driver I was recently working on just sets this to "always on", to achieve similar-to-existing behavior. so far that's always been my goal with new ports, even when there's potentially exotic hardware lurking beneath the surface. > Is there any existing scheme to allocating event numbers and/or event > names for a platform? Surely some of the events are common to most/all > platforms; it'd be a shame to make this harder than necessary for apps > that try to interpret the data in some way. Currently it appears the > events have been given the name from the cpu reference manual, and the > number chosen at random. Is this correct? it's worse than that on ppc, in fact! the events don't have any names, so I mangled the first few nouns and verbs in the event descriptions into symbolic names :(( generally, yeah, we should extend libop or something with an "easy" querying mechanism, for at least say cycles, instructions, micro-ops, cache misses, and pipeline stalls. nearly everything can count those. it would also be good if we improved the guess-an-appropriate-frequency code. > I notice that the code in 2.5.52 is lagging behind what's in oprofile > cvs, or even the 0.4 release. How does development between the two > source trees interact? you're right, they're a bit out of sync. but we have an evil plan :) the module accompanying the later 2.5 series kernels is plainly a better driver than the 2.4-supporting one residing in oprofile cvs. it is newer, has a cleaner design, and doesn't wrap system calls. unfortunately it is missing the p4 and hammer (and possibly ia64?) support we did in the fall, for the 2.4 driver. so what will and I have done recently (hopefully I'm not spiling any more beans than I did with the last internal email I posted here) is back-port the 2.5 driver to 2.4 and merge in the various CPU backends from the "old" 2.4 driver (including recently working hyper-threading). so we'll probably post most of this work sometime early in the new year, and that'll make further syncing between 2.4 and 2.5 series kernel and userspace quite a bit simpler, I think. -graydon |
From: John L. <le...@mo...> - 2002-12-21 02:46:20
|
On Fri, Dec 20, 2002 at 03:53:38PM -0800, Richard Henderson wrote: > Alpha has the ability to enable performance counters on a per-process > basis. I.e. enabled and disabled during the context switch between > user/kernel *and* based on a bit in the process' task control block. > Is there any way to use this with oprofile? If not, I can leave it > running all the time, or only in particular protection levels, so it's > not a bit deal, but it seems very useful. opcontrol/op_start lets you specify kernel/user counting, but I don't think it's the same thing. We could generalise this fairly easily though I think. As for per-task counting, the only real problem is deciding how the user should specify which tasks are of interest. oprofiled itself doesn't care, it will work on whatever info it's given. As I mentioned the question of how to generalise the setting parameters is the problem. In terms of the kernel/user interface it's probably just a matter of the alpha-specific code using oprofilefs_*() API to create parameters that are settable from user-space during opcontrol --setup regards john -- "ALL television is children's television." - Richard Adler |
From: John L. <le...@mo...> - 2002-12-21 02:20:38
|
On Fri, Dec 20, 2002 at 03:53:38PM -0800, Richard Henderson wrote: > names for a platform? Surely some of the events are common to most/all > platforms; it'd be a shame to make this harder than necessary for apps > that try to interpret the data in some way. Currently it appears the > events have been given the name from the cpu reference manual, and the > number chosen at random. Is this correct? Which numbers are you referring to ? The event numbers are not random. We need some work to virtualise the parameters across CPUs, currently they are rather intel-specific (event vs. unit mask etc.). I'm not sure of the best solution here, but I'm a bit nervous of trying to draw parallels between counters across architectures. The intention is that things can link against libop[++].a and get the information they need. I know this needs work. > I notice that the code in 2.5.52 is lagging behind what's in oprofile > cvs, or even the 0.4 release. How does development between the two > source trees interact? This is not true. oprofile cvs matches the current kernel. What you're probably seeing is that the old startup script (i.e. op_start) for 2.5 is currently installed as "op_start_25" instead of "op_start". This is just a silly bug that I hope to find time to fix tomorrow. But note we are deprecating op_start in favour of the more powerful opcontrol script, which should work under all circumstances. regards john -- "ALL television is children's television." - Richard Adler |
From: Richard H. <rt...@tw...> - 2002-12-20 23:53:49
|
Alpha has the ability to enable performance counters on a per-process basis. I.e. enabled and disabled during the context switch between user/kernel *and* based on a bit in the process' task control block. Is there any way to use this with oprofile? If not, I can leave it running all the time, or only in particular protection levels, so it's not a bit deal, but it seems very useful. Is there any existing scheme to allocating event numbers and/or event names for a platform? Surely some of the events are common to most/all platforms; it'd be a shame to make this harder than necessary for apps that try to interpret the data in some way. Currently it appears the events have been given the name from the cpu reference manual, and the number chosen at random. Is this correct? I notice that the code in 2.5.52 is lagging behind what's in oprofile cvs, or even the 0.4 release. How does development between the two source trees interact? r~ |
From: <no...@so...> - 2002-12-19 04:30:26
|
Bugs item #656123, was opened at 2002-12-19 05:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=656123&group_id=16191 Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Philippe Elie (phil_e) Assigned to: Philippe Elie (phil_e) Summary: --separate-samples: oprofpp failure Initial Comment: when profiling with --separate-samples oprofpp fail to retrieve samples files if no samples go to the application itself (i.e. the only samples for this application go in shared libs). oprofpp bailout with "oprofpp: Cannot locate any samples file." Fixed in current cvs. regard, Phil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=656123&group_id=16191 |
From: <no...@so...> - 2002-12-19 04:26:08
|
Bugs item #656123, was opened at 2002-12-19 05:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=656123&group_id=16191 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Philippe Elie (phil_e) Assigned to: Philippe Elie (phil_e) Summary: --separate-samples: oprofpp failure Initial Comment: when profiling with --separate-samples oprofpp fail to retrieve samples files if no samples go to the application itself (i.e. the only samples for this application go in shared libs). oprofpp bailout with "oprofpp: Cannot locate any samples file." Fixed in current cvs. regard, Phil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116191&aid=656123&group_id=16191 |
From: William C. <wc...@nc...> - 2002-12-19 01:44:15
|
Philippe Elie wrote: > William Cohen wrote: > >> The current opcontrol makes the assumption that the kernel has >> specific symbols indicating the start and end of the kernel. This has >> two drawbacks. First opcontrol hase problems with stripped kernels. >> The second is that not all kernel architectures use the same symbol >> names to indicate the start and end of the kernel. The attached patch >> uses > > > Just curious what arch ? A while back when I was seeing what would break on ppc, I dummy up a oprofile driver, 2.4 interface but no really data collection. I tried the op_start script and that was one of the things that broke. >> objdump and perl to extract the information about of the kernel code >> (.text section) and then computes the start and end. This approach >> only lists the .text range, not the .text.init segment for setup or >> the other non-code segements in the kernel. Is this reasonable? > > > Anyway can we profile init section ? oprofile can be started > only after kernel finished to exec init functions afaics That was my understanding that the initializer in .text.init all run before the profiling is running, so the profiler shouldn't see samples there. > >> >> 2002-12-18 Will Cohen <wc...@re...> >> >> * utils/opcontrol: Revise range computation. > > > ok > > regards, > Phil > > > |
From: William C. <wc...@nc...> - 2002-12-19 01:41:10
|
I checked it with a 2.5 interface backported to 2.4 kernel, so technically, I haven't checked it with a 2.5 kernel. I will try it out with a couple kernels on my home machine just to make sure that it works. Which versions of binutil would you be concerned about it working with? -Will John Levon wrote: > On Wed, Dec 18, 2002 at 12:43:31PM -0500, William Cohen wrote: > > >>The current opcontrol makes the assumption that the kernel has specific >>symbols indicating the start and end of the kernel. This has two > > > Have you checked this 2.5 kernel ? If it works for you, OK to commit. > > I'm a bit concerned about objdump formatting changes across binutils > versions though ... > > regards > john > > > ------------------------------------------------------- > This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! > Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, > MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. > T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |
From: Philippe E. <ph...@wa...> - 2002-12-19 00:17:54
|
William Cohen wrote: > The current opcontrol makes the assumption that the kernel has specific > symbols indicating the start and end of the kernel. This has two > drawbacks. First opcontrol hase problems with stripped kernels. The > second is that not all kernel architectures use the same symbol names to > indicate the start and end of the kernel. The attached patch uses Just curious what arch ? > objdump and perl to extract the information about of the kernel code > (.text section) and then computes the start and end. This approach only > lists the .text range, not the .text.init segment for setup or the other > non-code segements in the kernel. Is this reasonable? Anyway can we profile init section ? oprofile can be started only after kernel finished to exec init functions afaics > > 2002-12-18 Will Cohen <wc...@re...> > > * utils/opcontrol: Revise range computation. ok regards, Phil |
From: John L. <le...@mo...> - 2002-12-19 00:14:11
|
On Wed, Dec 18, 2002 at 12:43:31PM -0500, William Cohen wrote: > The current opcontrol makes the assumption that the kernel has specific > symbols indicating the start and end of the kernel. This has two Have you checked this 2.5 kernel ? If it works for you, OK to commit. I'm a bit concerned about objdump formatting changes across binutils versions though ... regards john |
From: William C. <wc...@nc...> - 2002-12-18 17:43:35
|
The current opcontrol makes the assumption that the kernel has specific symbols indicating the start and end of the kernel. This has two drawbacks. First opcontrol hase problems with stripped kernels. The second is that not all kernel architectures use the same symbol names to indicate the start and end of the kernel. The attached patch uses objdump and perl to extract the information about of the kernel code (.text section) and then computes the start and end. This approach only lists the .text range, not the .text.init segment for setup or the other non-code segements in the kernel. Is this reasonable? 2002-12-18 Will Cohen <wc...@re...> * utils/opcontrol: Revise range computation. -Will PS There will also need to be some changes in how $cpu_speed is obtained. Not all machines produce a "cpu MHZ" entry. |
From: Anton B. <an...@sa...> - 2002-12-18 14:51:46
|
> two of the P4 counters can be told to count page walks, either > data-tlb-miss or insn-tlb-miss (or both). I'm not sure whether you'd > like the extra information / noise this would give, or if it would just > obscure what you're aiming to measure. I forgot about the x86 situation. On ppc64 we have a TLB and a hashtable (all done in hardware) with linux pagetables in software. We could trigger on hashtable misses but its not the full picture because if the pte is in the linux pagetable we can handle it very quickly (it never hits do_page_fault). Anyway it sounds like this can stay local to my tree. Anton |
From: graydon h. <gr...@re...> - 2002-12-18 14:36:31
|
On Wed, 2002-12-18 at 03:36, Anton Blanchard wrote: > Im not distinguishing the type of page fault, just logging everthing > with a hook in do_page_fault. We could have different events for > different types of page faults. two of the P4 counters can be told to count page walks, either data-tlb-miss or insn-tlb-miss (or both). I'm not sure whether you'd like the extra information / noise this would give, or if it would just obscure what you're aiming to measure. -graydon |
From: Anton B. <an...@sa...> - 2002-12-18 08:38:03
|
Hi, This has probably been covered already, but Im finding it useful to get stats on where page faults occur. eg for a "university workload" (lots of shell scripts, gcc, troff etc) 30314 2.39116 __libc_start_main /lib/libc-2.3.1.so 31910 2.51705 internal_free /bin/bash 31936 2.5191 malloc_set_state /lib/libc-2.3.1.so 45878 3.61884 elf_dynamic_do_rela.3 /lib/ld-2.3.1.so 58238 4.59379 __strncpy_from_user vmlinux 77195 6.08912 internal_malloc /bin/bash 89079 7.02652 __clear_user vmlinux 174223 13.7427 file_read_actor vmlinux Im not distinguishing the type of page fault, just logging everthing with a hook in do_page_fault. We could have different events for different types of page faults. Thoughts? Anton |
From: Philippe E. <ph...@wa...> - 2002-12-18 05:31:09
|
This patch implement separating modules for each application. The patch is not intended to be applied as it but I'm dubious about a few points. Implementation is simple cause I re-use separating samples for shared libs. So - it add no new options --separate-samples is used to get this new features - pp tools are not changed at all, module and vmlinux files are considered as shared libs. If, later, there any point to treat them you already get the is_kernel flag in samples files - dae module/kernel mappings are added lazilly to proc->maps[] There is two FIXME in code, the third problem comes for kernel thread, I have no proper proc for them and don't see how I must handle them. The last problem is to document properly than HW irq samples go randomly to applications. regards, Phil |