[lkml]   [2006]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[Patch 0/9] Per-task delay accounting
    This is the next iteration of the delay accounting patches
    last posted at

    The major changes to the patches (and names of commenters whose concerns
    have been addressed) are:

    - considerable revision of the synchronous block I/O delay collection (Arjan)
    Now most delays seen in I/O submission are not being collected.
    - removal of dependency on schedstats by using common code (Nick)
    - removal of sysctl or dynamic configurability of delay accounting (Arjan)
    Now it it can be set on/off at boot time only.
    - providing I/O delays through /proc/<tgid>/stats (Andi)
    - revisions to the generic netlink interface (Jamal)

    Unaddressed comments are suggestions from Jamal on
    further improving the generic netlink interface which is ongoing.



    A short note on expected usage of this functionality follows which
    addresses a comment from Nick in the previous iteration.
    Basically, the patches measures a subset of the delays encountered
    by a task waiting for a resource such as cpu, disk I/O and page
    frames. Which subset is chosen depends on whether a task's delay
    is something that can be controlled by playing with its priority
    or rss limit etc.
    e.g. cpu delays can directly be affected by its static CPU priority.
    Similarly I/O delay can be affected by its I/O priority (assuming
    one uses the right iosched). In page frame delay, we only count
    the page faults due to swapin since that is directly affected by
    the rss limits for a task (well, ok, process).

    Delays can be used as feedback to decide whether something can/should
    be done about a task (or group of tasks) which is not performing
    as one expects.
    lists a fairly complicated way of using such data in
    workload management.

    At a simpler level, one can think of utilities that can use this data
    to control individual apps using a simple feedback loop.
    At this point we do not have such a utility.

    Of course, its useful to visually inspect such data. Some of it is
    being exported through /proc as suggested by Andi, but the primary
    interface is through a netlink socket so that userspace can get
    data for exiting tasks too.

    The netlink socket also allows userspace apps to efficiently
    collect delay data and group it in arbitrary ways
    (as envisaged by CKRM, CSA or ELSA) for reporting or
    control purposes.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-03-14 01:42    [W:0.036 / U:53.740 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site