06 May, 2014

3 commits


05 May, 2014

6 commits

  • Until now, cgroup->id has been used to identify all the associated
    csses and css_from_id() takes cgroup ID and returns the matching css
    by looking up the cgroup and then dereferencing the css associated
    with it; however, now that the lifetimes of cgroup and css are
    separate, this is incorrect and breaks on the unified hierarchy when a
    controller is disabled and enabled back again before the previous
    instance is released.

    This patch adds css->id which is a subsystem-unique ID and converts
    css_from_id() to look up by the new css->id instead. memcg is the
    only user of css_from_id() and also converted to use css->id instead.

    For traditional hierarchies, this shouldn't make any functional
    difference.

    Signed-off-by: Tejun Heo
    Acked-by: Michal Hocko
    Cc: Johannes Weiner
    Cc: Jianyu Zhan
    Acked-by: Li Zefan

    Tejun Heo
     
  • init_css() takes the cgroup the new css belongs to as an argument and
    initializes the new css's ->cgroup and ->parent pointers but doesn't
    acquire the matching reference counts. After the previous patch,
    create_css() puts init_css() and reference acquisition right next to
    each other. Let's move reference acquistion into init_css() and
    rename the function to init_and_link_css(). This makes sense and is
    easier to follow. This makes the root csses to hold a reference on
    cgrp_dfl_root.cgrp, which is harmless.

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • Currently, when create_css() fails in the middle, the half-initialized
    css is freed by invoking cgroup_subsys->css_free() directly. This
    patch updates the function so that it invokes RCU free path instead.
    As the RCU free path puts the parent css and owning cgroup, their
    references are now acquired right after a new css is successfully
    allocated.

    This doesn't make any visible difference now but is to enable
    implementing css->id and RCU protected lookup by such IDs.

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • Currently, cgroup_root->cgroup_idr is protected by cgroup_mutex, which
    ends up requiring cgroup_put() to be invoked under sleepable context.
    This is okay for now but is an unusual requirement and we'll soon add
    css->id which will have the same problem but won't be able to simply
    grab cgroup_mutex as removal will have to happen from css_release()
    which can't sleep.

    Introduce cgroup_idr_lock and idr_alloc/replace/remove() wrappers
    which protects the idr operations with the lock and use them for
    cgroup_root->cgroup_idr. cgroup_put() no longer needs to grab
    cgroup_mutex and css_from_id() is updated to always require RCU read
    lock instead of either RCU read lock or cgroup_mutex, which doesn't
    affect the existing users.

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • Currently, cgroup->id is allocated from 0, which is always assigned to
    the root cgroup; unfortunately, memcg wants to use ID 0 to indicate
    invalid IDs and ends up incrementing all IDs by one.

    It's reasonable to reserve 0 for special purposes. This patch updates
    cgroup core so that ID 0 is not used and the root cgroups get ID 1.
    The ID incrementing is removed form memcg.

    Signed-off-by: Tejun Heo
    Acked-by: Michal Hocko
    Cc: Johannes Weiner
    Acked-by: Li Zefan

    Tejun Heo
     
  • There's no reason to use atomic bitops for cgroup_subsys_state->flags,
    cgroup_root->flags and various subsys_masks. This patch updates those
    to use bitwise and/or operations instead and converts them form
    unsigned long to unsigned int.

    This makes the fields occupy (marginally) smaller space and makes it
    clear that they don't require atomicity.

    This patch doesn't cause any behavior difference.

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     

26 Apr, 2014

10 commits

  • Use pr_fmt and remove embedded prefixes.
    Realign modified multi-line statements to open parenthesis.
    Convert embedded function name to "%s: ", __func__

    Signed-off-by: Joe Perches
    Signed-off-by: Tejun Heo

    Joe Perches
     
  • As suggested by scripts/checkpatch.pl, substitude all pr_warning()
    with pr_warn().

    No functional change.

    Signed-off-by: Jianyu Zhan
    Signed-off-by: Tejun Heo

    Jianyu Zhan
     
  • 6612f05b88fa309c9 ("cgroup: unify pidlist and other file handling")
    has removed the only user of cgroup_pidlist_seq_operations :
    cgroup_pidlist_open().

    This patch removes it.

    Signed-off-by: Jianyu Zhan
    Signed-off-by: Tejun Heo

    Jianyu Zhan
     
  • 1d5be6b287c8efc87 ("cgroup: move module ref handling into
    rebind_subsystems()") makes parse_cgroupfs_options() no longer takes
    refcounts on subsystems.

    And unified hierachy makes parse_cgroupfs_options not need to call
    with cgroup_mutex held to protect the cgroup_subsys[].

    So this patch removes BUG_ON() and the comment. As the comment
    doesn't contain useful information afterwards, the whole comment is
    removed.

    Signed-off-by: Jianyu Zhan
    Signed-off-by: Tejun Heo

    Jianyu Zhan
     
  • Unified hierarchy will be the new version of cgroup interface. This
    patch adds Documentation/cgroups/unified-hierarchy.txt which describes
    the design and rationales of unified hierarchy.

    v2: Grammatical updates as per Randy Dunlap's review.

    Signed-off-by: Tejun Heo
    Cc: Randy Dunlap

    Tejun Heo
     
  • cgroup users often need a way to determine when a cgroup's
    subhierarchy becomes empty so that it can be cleaned up. cgroup
    currently provides release_agent for it; unfortunately, this mechanism
    is riddled with issues.

    * It delivers events by forking and execing a userland binary
    specified as the release_agent. This is a long deprecated method of
    notification delivery. It's extremely heavy, slow and cumbersome to
    integrate with larger infrastructure.

    * There is single monitoring point at the root. There's no way to
    delegate management of a subtree.

    * The event isn't recursive. It triggers when a cgroup doesn't have
    any tasks or child cgroups. Events for internal nodes trigger only
    after all children are removed. This again makes it impossible to
    delegate management of a subtree.

    * Events are filtered from the kernel side. "notify_on_release" file
    is used to subscribe to or suppress release event. This is
    unnecessarily complicated and probably done this way because event
    delivery itself was expensive.

    This patch implements interface file "cgroup.populated" which can be
    used to monitor whether the cgroup's subhierarchy has tasks in it or
    not. Its value is 0 if there is no task in the cgroup and its
    descendants; otherwise, 1, and kernfs_notify() notificaiton is
    triggers when the value changes, which can be monitored through poll
    and [di]notify.

    This is a lot ligther and simpler and trivially allows delegating
    management of subhierarchy - subhierarchy monitoring can block further
    propgation simply by putting itself or another process in the root of
    the subhierarchy and monitor events that it's interested in from there
    without interfering with monitoring higher in the tree.

    v2: Patch description updated as per Serge.

    v3: "cgroup.subtree_populated" renamed to "cgroup.populated". The
    subtree_ prefix was a bit confusing because
    "cgroup.subtree_control" uses it to denote the tree rooted at the
    cgroup sans the cgroup itself while the populated state includes
    the cgroup itself.

    Signed-off-by: Tejun Heo
    Acked-by: Serge Hallyn
    Acked-by: Li Zefan
    Cc: Lennart Poettering

    Tejun Heo
     
  • …/gregkh/driver-core into for-3.16

    Pull in driver-core-next to receive kernfs_notify() updates which will
    be used by the planned "cgroup.populated" implementation.

    Signed-off-by: Tejun Heo <tj@kernel.org>

    Tejun Heo
     
  • Support for uevent_helper, aka hotplug, is not required on many systems
    these days but it can still be enabled via sysfs or sysctl.

    Reported-by: Darren Shepherd
    Signed-off-by: Michael Marineau
    Signed-off-by: Greg Kroah-Hartman

    Michael Marineau
     
  • kernfs_notify() is used to indicate either new data is available or
    the content of a file has changed. It currently only triggers poll
    which may not be the most convenient to monitor especially when there
    are a lot to monitor. Let's hook it up to fsnotify too so that the
    events can be monitored via inotify too.

    fsnotify_modify() requires file * but kernfs_notify() doesn't have any
    specific file associated; however, we can walk all super_blocks
    associated with a kernfs_root and as kernfs always associate one ino
    with inode and one dentry with an inode, it's trivial to look up the
    dentry associated with a given kernfs_node. As any active monitor
    would pin dentry, just looking up existing dentry is enough. This
    patch looks up the dentry associated with the specified kernfs_node
    and generates events equivalent to fsnotify_modify().

    Note that as fsnotify doesn't provide fsnotify_modify() equivalent
    which can be called with dentry, kernfs_notify() directly calls
    fsnotify_parent() and fsnotify(). It might be better to add a wrapper
    in fsnotify.h instead.

    Signed-off-by: Tejun Heo
    Cc: John McCutchan
    Cc: Robert Love
    Cc: Eric Paris
    Signed-off-by: Greg Kroah-Hartman

    Tejun Heo
     
  • Currently, there's no way to find out which super_blocks are
    associated with a given kernfs_root. Let's implement it - the planned
    inotify extension to kernfs_notify() needs it.

    Make kernfs_super_info point back to the super_block and chain it at
    kernfs_root->supers.

    Signed-off-by: Tejun Heo
    Signed-off-by: Greg Kroah-Hartman

    Tejun Heo
     

23 Apr, 2014

13 commits

  • cgroup is switching away from multiple hierarchies and will use one
    unified default hierarchy where controllers can be dynamically enabled
    and disabled per subtree. The default hierarchy will serve as the
    unified hierarchy to which all controllers are attached and a css on
    the default hierarchy would need to also serve the tasks of descendant
    cgroups which don't have the controller enabled - ie. the tree may be
    collapsed from leaf towards root when viewed from specific
    controllers. This has been implemented through effective css in the
    previous patches.

    This patch finally implements dynamic subtree controller
    enable/disable on the default hierarchy via a new knob -
    "cgroup.subtree_control" which controls which controllers are enabled
    on the child cgroups. Let's assume a hierarchy like the following.

    root - A - B - C
    \ D

    root's "cgroup.subtree_control" determines which controllers are
    enabled on A. A's on B. B's on C and D. This coincides with the
    fact that controllers on the immediate sub-level are used to
    distribute the resources of the parent. In fact, it's natural to
    assume that resource control knobs of a child belong to its parent.
    Enabling a controller in "cgroup.subtree_control" declares that
    distribution of the respective resources of the cgroup will be
    controlled. Note that this means that controller enable states are
    shared among siblings.

    The default hierarchy has an extra restriction - only cgroups which
    don't contain any task may have controllers enabled in
    "cgroup.subtree_control". Combined with the other properties of the
    default hierarchy, this guarantees that, from the view point of
    controllers, tasks are only on the leaf cgroups. In other words, only
    leaf csses may contain tasks. This rules out situations where child
    cgroups compete against internal tasks of the parent, which is a
    competition between two different types of entities without any clear
    way to determine resource distribution between the two. Different
    controllers handle it differently and all the implemented behaviors
    are ambiguous, ad-hoc, cumbersome and/or just wrong. Having this
    structural constraints imposed from cgroup core removes the burden
    from controller implementations and enables showing one consistent
    behavior across all controllers.

    When a controller is enabled or disabled, css associations for the
    controller in the subtrees of each child should be updated. After
    enabling, the whole subtree of a child should point to the new css of
    the child. After disabling, the whole subtree of a child should point
    to the cgroup's css. This is implemented by first updating cgroup
    states such that cgroup_e_css() result points to the appropriate css
    and then invoking cgroup_update_dfl_csses() which migrates all tasks
    in the affected subtrees to the self cgroup on the default hierarchy.

    * When read, "cgroup.subtree_control" lists all the currently enabled
    controllers on the children of the cgroup.

    * White-space separated list of controller names prefixed with either
    '+' or '-' can be written to "cgroup.subtree_control". The ones
    prefixed with '+' are enabled on the controller and '-' disabled.

    * A controller can be enabled iff the parent's
    "cgroup.subtree_control" enables it and disabled iff no child's
    "cgroup.subtree_control" has it enabled.

    * If a cgroup has tasks, no controller can be enabled via
    "cgroup.subtree_control". Likewise, if "cgroup.subtree_control" has
    some controllers enabled, tasks can't be migrated into the cgroup.

    * All controllers which aren't bound on other hierarchies are
    automatically associated with the root cgroup of the default
    hierarchy. All the controllers which are bound to the default
    hierarchy are listed in the read-only file "cgroup.controllers" in
    the root directory.

    * "cgroup.controllers" in all non-root cgroups is read-only file whose
    content is equal to that of "cgroup.subtree_control" of the parent.
    This indicates which controllers can be used in the cgroup's
    "cgroup.subtree_control".

    This is still experimental and there are some holes, one of which is
    that ->can_attach() failure during cgroup_update_dfl_csses() may leave
    the cgroups in an undefined state. The issues will be addressed by
    future patches.

    v2: Non-root cgroups now also have "cgroup.controllers".

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • Unified hierarchy implementation would require re-migrating tasks onto
    the same cgroup on the default hierarchy to reflect updated effective
    csses. Update cgroup_migrate_prepare_dst() so that it accepts NULL as
    the destination cgrp. When NULL is specified, the destination is
    considered to be the cgroup on the default hierarchy associated with
    each css_set.

    After this change, the identity check in cgroup_migrate_add_src()
    isn't sufficient for noop detection as the associated csses may change
    without any cgroup association changing. The only way to tell whether
    a migration is noop or not is testing whether the source and
    destination csets are identical. The noop check in
    cgroup_migrate_add_src() is removed and cset identity test is added to
    cgroup_migreate_prepare_dst(). If it's detected that source and
    destination csets are identical, the cset is removed removed from
    @preloaded_csets and all the migration nodes are cleared which makes
    cgroup_migrate() ignore the cset.

    Also, make the function append the destination css_sets to
    @preloaded_list so that destination css_sets always come after source
    css_sets.

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • Because the default root couldn't have any non-root csses attached to
    it, rebinding away from it was always allowed; however, the default
    hierarchy will soon host the unified hierarchy and have non-root csses
    so the rebind restrictions need to be updated accordingly.

    Instead of special casing rebinding from the default hierarchy and
    then checking whether the source hierarchy has children cgroups, which
    implies non-root csses for !dfl hierarchies, simply check whether the
    source hierarchy has non-root csses for the subsystem using
    css_next_child().

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • To implement the unified hierarchy behavior, we'll need to be able to
    determine the associated cgroup on the default hierarchy from css_set.
    Let's add css_set->dfl_cgrp so that it can be accessed conveniently
    and efficiently.

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • Now that effective css handling has been added and iterators updated
    accordingly, it's safe to allow cgroup creation in the default
    hierarchy. Unblock cgroup creation in the default hierarchy.

    As the default hierarchy will implement explicit enabling and
    disabling of controllers on each cgroup, suppress automatic css
    enabling on cgroup creation.

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • After a css finishes offlining, offline_css() mistakenly performs
    RCU_INIT_POINTER(css->cgroup->subsys[ss->id], css) which just sets the
    cgroup->subsys[] pointer to the current value. The intention was to
    clear it after offline is complete, not reassign the same value.

    Update it to assign NULL instead of the current value. This makes
    cgroup_css() to return NULL once offline is complete. All the
    existing users of the function either can handle NULL return already
    or guarantee that the css doesn't get offlined.

    While this is a bugfix, as css lifetime is currently tied to the
    cgroup it belongs to, this bug doesn't cause any actual problems.

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • Currently, css_task_iter iterates tasks associated with a css by
    visiting each css_set associated with the owning cgroup and walking
    tasks of each of them. This works fine for !unified hierarchies as
    each cgroup has its own css for each associated subsystem on the
    hierarchy; however, on the planned unified hierarchy, a cgroup may not
    have csses associated and its tasks would be considered associated
    with the matching css of the nearest ancestor which has the subsystem
    enabled.

    This means that on the default unified hierarchy, just walking all
    tasks associated with a cgroup isn't enough to walk all tasks which
    are associated with the specified css. If any of its children doesn't
    have the matching css enabled, task iteration should also include all
    tasks from the subtree. We already added cgroup->e_csets[] to list
    all css_sets effectively associated with a given css and walk css_sets
    on that list instead to achieve such iteration.

    This patch updates css_task_iter iteration such that it walks css_sets
    on cgroup->e_csets[] instead of cgroup->cset_links if iteration is
    requested on an non-dummy css. Thanks to the previous iteration
    update, this change can be achieved with the addition of
    css_task_iter->ss and minimal updates to css_advance_task_iter() and
    css_task_iter_start().

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • This patch reorganizes css_task_iter so that adding effective css
    support is easier.

    * s/->cset_link/->cset_pos/ and s/->task/->task_pos/ for consistency

    * ->origin_css is used to determine whether the iteration reached the
    last css_set. Replace it with explicit ->cset_head so that
    css_advance_task_iter() doesn't have to know the termination
    condition directly.

    * css_task_iter_next() currently assumes that it's walking list of
    cgrp_cset_link and reaches into the current cset through the current
    link to determine the termination conditions for task walking. As
    this won't always be true for effective css walking, add
    ->tasks_head and ->mg_tasks_head and use them to control task
    walking so that css_task_iter_next() doesn't have to know how
    css_sets are being walked.

    This patch doesn't make any behavior changes. The iteration logic
    stays unchanged after the patch.

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • css_next_child() walks the children of the specified css. It does
    this by finding the next cgroup and then returning the requested css.
    On the default unified hierarchy, a cgroup may not have a css
    associated with it even if the hierarchy has the subsystem enabled.
    This patch updates css_next_child() so that it skips children without
    the requested css associated.

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • On the default unified hierarchy, a cgroup may be associated with
    csses of its ancestors, which means that a css of a given cgroup may
    be associated with css_sets of descendant cgroups. This means that we
    can't walk all tasks associated with a css by iterating the css_sets
    associated with the cgroup as there are css_sets which are pointing to
    the css but linked on the descendants.

    This patch adds per-subsystem list heads cgroup->e_csets[]. Any
    css_set which is pointing to a css is linked to
    css->cgroup->e_csets[$SUBSYS_ID] through
    css_set->e_cset_node[$SUBSYS_ID]. The lists are protected by
    css_set_rwsem and will allow us to walk all css_sets associated with a
    given css so that we can find out all associated tasks.

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • In the planned default unified hierarchy, controllers may get
    dynamically attached to and detached from a cgroup and a cgroup may
    not have csses for all the controllers associated with the hierarchy.

    When a cgroup doesn't have its own css for a given controller, the css
    of the nearest ancestor with the controller enabled will be used,
    which is called the effective css. This patch introduces
    cgroup_e_css() and for_each_e_css() to access the effective csses and
    convert compare_css_sets(), find_existing_css_set() and
    cgroup_migrate() to use the effective csses so that they can handle
    cgroups with partial csses correctly.

    This means that for two css_sets to be considered identical, they
    should have both matching csses and cgroups. compare_css_sets()
    already compares both, not for correctness but for optimization. As
    this now becomes a matter of correctness, update the comments
    accordingly.

    For all !default hierarchies, cgroup_e_css() always equals
    cgroup_css(), so this patch doesn't change behavior.

    While at it, fix incorrect locking comment for for_each_css().

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • 944196278d3d ("cgroup: move ->subsys_mask from cgroupfs_root to
    cgroup") moved ->subsys_mask from cgroup_root to cgroup to prepare for
    the unified hierarhcy; however, it turns out that carrying the
    subsys_mask of the children in the parent, instead of itself, is a lot
    more natural. This patch restores cgroup_root->subsys_mask and morphs
    cgroup->subsys_mask into cgroup->child_subsys_mask.

    * Uses of root->cgrp.subsys_mask are restored to root->subsys_mask.

    * Remove automatic setting and clearing of cgrp->subsys_mask and
    instead just inherit ->child_subsys_mask from the parent during
    cgroup creation. Note that this doesn't affect any current
    behaviors.

    * Undo __kill_css() separation.

    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     
  • cgroup_apply_cftypes() skip creating or removing files if the
    subsystem is attached to the default hierarchy, which led to missing
    files in the root of the default hierarchy.

    Skipping made sense when the default hierarchy was dummy; however, now
    that the default hierarchy is full functional and planned to be used
    as the unified hierarchy, it shouldn't be skipped over.

    Reported-by: Li Zefan
    Signed-off-by: Tejun Heo
    Acked-by: Li Zefan

    Tejun Heo
     

21 Apr, 2014

4 commits


20 Apr, 2014

4 commits

  • …it/jolsa/perf into perf/urgent

    Pull perf/urgent fixes from Jiri Olsa:

    User visible changes:

    * Adjust symbols in VDSO to properly resolve its function names (Vladimir Nikulichev)

    * Improve error reporting for record session failure (Adrien BAK)

    * Fix 'Min time' counting in report command (Alexander Yarygin)

    Signed-off-by: Jiri Olsa <jolsa@redhat.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

    Ingo Molnar
     
  • In the current version, when using perf record, if something goes
    wrong in tools/perf/builtin-record.c:375
    session = perf_session__new(file, false, NULL);

    The error message:
    "Not enough memory for reading per file header"

    is issued. This error message seems to be outdated and is not very
    helpful. This patch proposes to replace this error message by
    "Perf session creation failed"

    I believe this issue has been brought to lkml:
    https://lkml.org/lkml/2014/2/24/458
    although this patch only tackles a (small) part of the issue.

    Additionnaly, this patch improves error reporting in
    tools/perf/util/data.c open_file_write.

    Currently, if the call to open fails, the user is unaware of it.
    This patch logs the error, before returning the error code to
    the caller.

    Reported-by: Will Deacon
    Signed-off-by: Adrien BAK
    Link: http://lkml.kernel.org/r/1397786443.3093.4.camel@beast
    [ Reorganize the changelog into paragraphs ]
    [ Added empty line after fd declaration in open_file_write ]
    Signed-off-by: Jiri Olsa

    Adrien BAK
     
  • pert-report doesn't resolve function names in VDSO:

    $ perf report --stdio -g flat,0.0,15,callee --sort pid
    ...
    8.76%
    0x7fff6b1fe861
    __gettimeofday
    ACE_OS::gettimeofday()
    ...

    In this case symbol values should be adjusted the same way as for executables,
    relocatable objects and prelinked libraries.

    After fix:

    $ perf report --stdio -g flat,0.0,15,callee --sort pid
    ...
    8.76%
    __vdso_gettimeofday
    __gettimeofday
    ACE_OS::gettimeofday()

    Signed-off-by: Vladimir Nikulichev
    Tested-by: Namhyung Kim
    Reviewed-by: Adrian Hunter
    Link: http://lkml.kernel.org/r/969812.163009436-sendEmail@nvs
    Signed-off-by: Jiri Olsa

    Vladimir Nikulichev
     
  • Every event in the perf-kvm has a 'stats' structure, which contains
    max/min/average/etc times of handling this event.
    The problem is that the 'perf-kvm stat report' command always shows
    that 'min time' is 0us for every event. Example:

    # perf kvm stat report

    Analyze events for all VCPUs:

    VM-EXIT Samples Samples% Time% Min Time Max Time Avg time
    [..]
    0xB2 MSCH 12 0.07% 0.00% 0us 8us 7.31us ( +- 2.11% )
    0xB2 CHSC 12 0.07% 0.00% 0us 18us 9.39us ( +- 9.49% )
    0xB2 STPX 8 0.05% 0.00% 0us 2us 1.88us ( +- 7.18% )
    0xB2 STSI 7 0.04% 0.00% 0us 44us 16.49us ( +- 38.20% )
    [..]

    This happens because the 'stats' structure is not initialized and
    stats->min equals to 0. Lets initialize the structure for every
    event after its allocation using init_stats() function. This initializes
    stats->min to -1 and makes 'Min time' statistics counting work:

    # perf kvm stat report

    Analyze events for all VCPUs:

    VM-EXIT Samples Samples% Time% Min Time Max Time Avg time
    [..]
    0xB2 MSCH 12 0.07% 0.00% 6us 8us 7.31us ( +- 2.11% )
    0xB2 CHSC 12 0.07% 0.00% 7us 18us 9.39us ( +- 9.49% )
    0xB2 STPX 8 0.05% 0.00% 1us 2us 1.88us ( +- 7.18% )
    0xB2 STSI 7 0.04% 0.00% 1us 44us 16.49us ( +- 38.20% )
    [..]

    Signed-off-by: Alexander Yarygin
    Signed-off-by: Christian Borntraeger
    Reviewed-by: David Ahern
    Link: http://lkml.kernel.org/r/1397053319-2130-3-git-send-email-borntraeger@de.ibm.com
    [ Fixing the perf examples changelog output ]
    Signed-off-by: Jiri Olsa

    Alexander Yarygin