17 Dec, 2008

1 commit


10 Dec, 2008

1 commit

  • This patch restores default values for:

    /dev/oprofile/cpu_buffer_size
    /dev/oprofile/buffer_watershed
    /dev/oprofile/buffer_size

    when creating the oprofilefs:

    # opcontrol --deinit
    # opcontrol --init
    # cat /dev/oprofile/cpu_buffer_size
    8192
    # echo 5123 > /dev/oprofile/cpu_buffer_size
    # cat /dev/oprofile/cpu_buffer_size
    5123
    # opcontrol --deinit
    # opcontrol --init
    # cat /dev/oprofile/cpu_buffer_size
    8192
    # opcontrol --deinit

    This sets the values in a defined state. Before, there was no way to
    restore the defaults without rebooting the system or reloading the
    module.

    Signed-off-by: Robert Richter

    Robert Richter
     

16 Oct, 2008

2 commits


24 Sep, 2008

1 commit


26 Jul, 2008

1 commit

  • 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: Jason Yeh
    Signed-off-by: Robert Richter
    Cc: oprofile-list
    Signed-off-by: Ingo Molnar

    Jason Yeh
     

13 Feb, 2007

1 commit

  • Many struct file_operations in the kernel can be "const". Marking them const
    moves these to the .rodata section, which avoids false sharing with potential
    dirty data. In addition it'll catch accidental writes at compile time to
    these shared resources.

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

    Arjan van de Ven
     

26 Apr, 2005

1 commit


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