1. 10 12月, 2008 1 次提交
    • R
      oprofile: set values to default when creating oprofilefs · 37ca5eb3
      Robert Richter 提交于
      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: NRobert Richter <robert.richter@amd.com>
      37ca5eb3
  2. 16 10月, 2008 2 次提交
  3. 24 9月, 2008 1 次提交
  4. 26 7月, 2008 1 次提交
    • J
      Oprofile Multiplexing Patch · 1a960b40
      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>
      1a960b40
  5. 13 2月, 2007 1 次提交
  6. 26 4月, 2005 1 次提交
  7. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      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!
      1da177e4