10 Jan, 2009

1 commit

  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile: (31 commits)
    powerpc/oprofile: fix whitespaces in op_model_cell.c
    powerpc/oprofile: IBM CELL: add SPU event profiling support
    powerpc/oprofile: fix cell/pr_util.h
    powerpc/oprofile: IBM CELL: cleanup and restructuring
    oprofile: make new cpu buffer functions part of the api
    oprofile: remove #ifdef CONFIG_OPROFILE_IBS in non-ibs code
    ring_buffer: fix ring_buffer_event_length()
    oprofile: use new data sample format for ibs
    oprofile: add op_cpu_buffer_get_data()
    oprofile: add op_cpu_buffer_add_data()
    oprofile: rework implementation of cpu buffer events
    oprofile: modify op_cpu_buffer_read_entry()
    oprofile: add op_cpu_buffer_write_reserve()
    oprofile: rename variables in add_ibs_begin()
    oprofile: rename add_sample() in cpu_buffer.c
    oprofile: rename variable ibs_allowed to has_ibs in op_model_amd.c
    oprofile: making add_sample_entry() inline
    oprofile: remove backtrace code for ibs
    oprofile: remove unused ibs macro
    oprofile: remove unused components in struct oprofile_cpu_buffer
    ...

    Linus Torvalds
     

08 Jan, 2009

15 commits


06 Jan, 2009

1 commit


01 Jan, 2009

1 commit

  • struct dentry is one of the most critical structures in the kernel. So it's
    sad to see it going neglected.

    With CONFIG_PROFILING turned on (which is probably the common case at least
    for distros and kernel developers), sizeof(struct dcache) == 208 here
    (64-bit). This gives 19 objects per slab.

    I packed d_mounted into a hole, and took another 4 bytes off the inline
    name length to take the padding out from the end of the structure. This
    shinks it to 200 bytes. I could have gone the other way and increased the
    length to 40, but I'm aiming for a magic number, read on...

    I then got rid of the d_cookie pointer. This shrinks it to 192 bytes. Rant:
    why was this ever a good idea? The cookie system should increase its hash
    size or use a tree or something if lookups are a problem. Also the "fast
    dcookie lookups" in oprofile should be moved into the dcookie code -- how
    can oprofile possibly care about the dcookie_mutex? It gets dropped after
    get_dcookie() returns so it can't be providing any sort of protection.

    At 192 bytes, 21 objects fit into a 4K page, saving about 3MB on my system
    with ~140 000 entries allocated. 192 is also a multiple of 64, so we get
    nice cacheline alignment on 64 and 32 byte line systems -- any given dentry
    will now require 3 cachelines to touch all fields wheras previously it
    would require 4.

    I know the inline name size was chosen quite carefully, however with the
    reduction in cacheline footprint, it should actually be just about as fast
    to do a name lookup for a 36 character name as it was before the patch (and
    faster for other sizes). The memory footprint savings for names which are
    36 bytes long should more than make up for the memory cost for
    33-36 byte names.

    Performance is a feature...

    Signed-off-by: Al Viro

    Nick Piggin
     

30 Dec, 2008

6 commits


29 Dec, 2008

2 commits


17 Dec, 2008

1 commit


11 Dec, 2008

2 commits

  • The number of lost samples could be greater than the number of
    received samples. This patches fixes this. The implementation
    introduces return values for add_sample() and add_code().

    Signed-off-by: Robert Richter

    Robert Richter
     
  • This function is no longer available after the port to the new ring
    buffer. Its removal can lead to incomplete sampling sequences since
    IBS samples and backtraces are transfered in multiple samples. Due to
    a full buffer, samples could be lost any time. The userspace daemon
    has to live with such incomplete sampling sequences as long as the
    data within one sample is consistent.

    This will be fixed by changing the internal buffer data there all data
    of one IBS sample or a backtrace is packed in a single ring buffer
    entry. This is possible since the new ring buffer supports variable
    data size.

    Signed-off-by: Robert Richter

    Robert Richter
     

10 Dec, 2008

10 commits

  • This patch replaces the current oprofile cpu buffer implementation
    with the ring buffer provided by the tracing framework. The motivation
    here is to leave the pain of implementing ring buffers to others. Oh,
    no, there are more advantages. Main reason is the support of different
    sample sizes that could be stored in the buffer. Use cases for this
    are IBS and Cell spu profiling. Using the new ring buffer ensures
    valid and complete samples and allows copying the cpu buffer stateless
    without knowing its content. Second it will use generic kernel API and
    also reduce code size. And hopefully, there are less bugs.

    Since the new tracing ring buffer implementation uses spin locks to
    protect the buffer during read/write access, it is difficult to use
    the buffer in an NMI handler. In this case, writing to the buffer by
    the NMI handler (x86) could occur also during critical sections when
    reading the buffer. To avoid this, there are 2 buffers for independent
    read and write access. Read access is in process context only, write
    access only in the NMI handler. If the read buffer runs empty, both
    buffers are swapped atomically. There is potentially a small window
    during swapping where the buffers are disabled and samples could be
    lost.

    Using 2 buffers is a little bit overhead, but the solution is clear
    and does not require changes in the ring buffer implementation. It can
    be changed to a single buffer solution when the ring buffer access is
    implemented as non-locking atomic code.

    The new buffer requires more size to store the same amount of samples
    because each sample includes an u32 header. Also, there is more code
    to execute for buffer access. Nonetheless, the buffer implementation
    is proven in the ftrace environment and worth to use also in oprofile.

    Patches that changes the internal IBS buffer usage will follow.

    Cc: Steven Rostedt
    Signed-off-by: Robert Richter

    Robert Richter
     
  • This is in preparation for changes in the cpu buffer implementation.

    Signed-off-by: Robert Richter

    Robert Richter
     
  • This is in preparation for changes in the cpu buffer implementation.

    Signed-off-by: Robert Richter

    Robert Richter
     
  • This is in preparation for changes in the cpu buffer implementation.

    Signed-off-by: Robert Richter

    Robert Richter
     
  • This is in preparation for changes in the cpu buffer implementation.

    Signed-off-by: Robert Richter

    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: Robert Richter

    Robert Richter
     
  • Signed-off-by: Robert Richter

    Robert Richter
     
  • Signed-off-by: Robert Richter

    Robert Richter
     
  • Signed-off-by: Robert Richter

    Robert Richter
     
  • This fixes the coding style of some comments.

    Signed-off-by: Robert Richter

    Robert Richter
     

28 Oct, 2008

1 commit