15 Oct, 2010

1 commit

  • Commit e9677b3ce (oprofile, ARM: Use oprofile_arch_exit() to
    cleanup on failure) caused oprofile_perf_exit to be called
    in the cleanup path of oprofile_perf_init. The __exit tag
    for oprofile_perf_exit should therefore be dropped.

    The same has to be done for exit_driverfs as well, as this
    function is called from oprofile_perf_exit. Else, we get
    the following two linker errors.

    LD .tmp_vmlinux1
    `oprofile_perf_exit' referenced in section `.init.text' of arch/arm/oprofile/built-in.o: defined in discarded section `.exit.text' of arch/arm/oprofile/built-in.o
    make: *** [.tmp_vmlinux1] Error 1

    LD .tmp_vmlinux1
    `exit_driverfs' referenced in section `.text' of arch/arm/oprofile/built-in.o: defined in discarded section `.exit.text' of arch/arm/oprofile/built-in.o
    make: *** [.tmp_vmlinux1] Error 1

    Signed-off-by: Anand Gadiyar
    Cc: Will Deacon
    Signed-off-by: Robert Richter

    Anand Gadiyar
     

11 Oct, 2010

2 commits

  • Move the perf-events backend from arch/arm/oprofile into
    drivers/oprofile so that the code can be shared between architectures.

    This allows each architecture to maintain only a single copy of the PMU
    accessor functions instead of one for both perf and OProfile. It also
    becomes possible for other architectures to delete much of their
    OProfile code in favour of the common code now available in
    drivers/oprofile/oprofile_perf.c.

    Signed-off-by: Matt Fleming
    Tested-by: Will Deacon
    Signed-off-by: Robert Richter

    Matt Fleming
     
  • Make op_name_from_perf_id() global so that we have a way for each
    architecture to construct an oprofile name for op->cpu_type. We need to
    remove the argument from the function prototype so that we can hide all
    implementation details inside the function.

    Signed-off-by: Matt Fleming
    Signed-off-by: Robert Richter

    Matt Fleming
     

20 Jul, 2009

1 commit

  • The number of hardware counters is limited. The multiplexing feature
    enables OProfile to gather more events than counters are provided by
    the hardware. This is realized by switching between events at an user
    specified time interval.

    A new file (/dev/oprofile/time_slice) is added for the user to specify
    the timer interval in ms. If the number of events to profile is higher
    than the number of hardware counters available, the patch will
    schedule a work queue that switches the event counter and re-writes
    the different sets of values into it. The switching mechanism needs to
    be implemented for each architecture to support multiplexing. This
    patch only implements AMD CPU support, but multiplexing can be easily
    extended for other models and architectures.

    There are follow-on patches that rework parts of this patch.

    Signed-off-by: Jason Yeh
    Signed-off-by: Robert Richter

    Jason Yeh
     

12 Jun, 2009

1 commit


11 Jun, 2009

1 commit


08 Jan, 2009

1 commit


10 Dec, 2008

1 commit


21 Oct, 2008

1 commit

  • The issue is the SPU code is not holding the kernel mutex lock while
    adding samples to the kernel buffer.

    This patch creates per SPU buffers to hold the data. Data
    is added to the buffers from in interrupt context. The data
    is periodically pushed to the kernel buffer via a new Oprofile
    function oprofile_put_buff(). The oprofile_put_buff() function
    is called via a work queue enabling the funtion to acquire the
    mutex lock.

    The existing user controls for adjusting the per CPU buffer
    size is used to control the size of the per SPU buffers.
    Similarly, overflows of the SPU buffers are reported by
    incrementing the per CPU buffer stats. This eliminates the
    need to have architecture specific controls for the per SPU
    buffers which is not acceptable to the OProfile user tool
    maintainer.

    The export of the oprofile add_event_entry() is removed as it
    is no longer needed given this patch.

    Note, this patch has not addressed the issue of indexing arrays
    by the spu number. This still needs to be fixed as the spu
    numbering is not guarenteed to be 0 to max_num_spus-1.

    Signed-off-by: Carl Love
    Signed-off-by: Maynard Johnson
    Signed-off-by: Arnd Bergmann
    Acked-by: Acked-by: Robert Richter
    Signed-off-by: Benjamin Herrenschmidt

    Carl Love
     

26 Jul, 2008

1 commit


21 Jul, 2007

1 commit

  • From: Maynard Johnson

    This patch updates the existing arch/powerpc/oprofile/op_model_cell.c
    to add in the SPU profiling capabilities. In addition, a 'cell' subdirectory
    was added to arch/powerpc/oprofile to hold Cell-specific SPU profiling code.
    Exports spu_set_profile_private_kref and spu_get_profile_private_kref which
    are used by OProfile to store private profile information in spufs data
    structures.

    Also incorporated several fixes from other patches (rrn). Check pointer
    returned from kzalloc. Eliminated unnecessary cast. Better error
    handling and cleanup in the related area. 64-bit unsigned long parameter
    was being demoted to 32-bit unsigned int and eventually promoted back to
    unsigned long.

    Signed-off-by: Carl Love
    Signed-off-by: Maynard Johnson
    Signed-off-by: Bob Nelson
    Signed-off-by: Arnd Bergmann
    Acked-by: Paul Mackerras

    Bob Nelson
     

29 Mar, 2006

2 commits

  • Mark the f_ops members of inodes as const, as well as fix the
    ripple-through this causes by places that copy this f_ops and then "do
    stuff" with it.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Alexey Dobriyan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     
  • On ppc64 we look at a profiling register to work out the sample address and
    if it was in userspace or kernel.

    The backtrace interface oprofile_add_sample does not allow this. Create
    oprofile_add_ext_sample and make oprofile_add_sample use it too.

    Signed-off-by: Anton Blanchard
    Cc: Philippe Elie
    Cc: John Levon
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Brian Rogan
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds