lkml.org 
[lkml]   [2012]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[PATCH RFC v2 0/1] Flexible proportions
    Date

    Hello,

    so I got back to my idea of providing code for computing event proportions
    where aging period is not dependent on the number of events happening (so
    that aging works well both with fast storage and slow USB sticks in the same
    system).

    The basic idea is that we compute proportions as:
    p_j = (\Sum_{i>=0} x_{i,j}/2^{i+1}) / (\Sum_{i>=0} x_i/2^{i+1})

    Where x_{i,j} is j's number of events in i-th last time period and x_i is
    total number of events in i-th last time period.

    Note that when x_i's are all the same (as is the case with current
    proportion code), this expression simplifies to the expression defining
    current proportions which is:
    p_j = \Sum_{i>=0} x_{i,j}/2^{i+1} / t

    where t is the lenght of the aging period.

    In fact, if we are in the middle of the period, the proportion computed by
    the current code is:
    p_j = (x_0 + \Sum_{i>=1} x_{i,j}/2^{i+1}) / (t' + t)

    where t' is total number of events in the running period and t is the lenght
    of the aging period. So there is event more similarity.

    Similarly as with current proportion code, it is simple to compute update
    proportion after several periods have elapsed. For each proportion we store
    the numerator of our fraction and the number of period when the proportion
    was last updated. In global proportion structure we compute the denominator
    of the fraction which is the same for all event types. So catch up with missed
    periods boils down to shifting the numerator by the number of missed periods
    and that's it. For more details, please see the code.

    I've also run a few tests (I've created a userspace wrapper to allow me to
    run proportion code in userpace and arbitrarily generate events for it) to
    compare the behavior of old and new code. You can see them at
    http://beta.suse.com/private/jack/flex_proportions/ In all the tests new code
    showed faster convergence to current event proportions (I tried to
    realistically set period_shift for fixed proportions). Also in the last test
    we see that if period_shift is decreased, then current proportions become more
    sensitive to short term fluctuations in event rate so just decreasing
    period_shift isn't a good solution to slower convergence. If anyone has other
    idea what to try, I can do that - it should be simple enough to implement in
    my testing tool.

    So my plan, if people are happy with the new proportion code, would be to
    switch at least bdi writeout proportion to the new code. I can also check
    other users to see whether it would make sense for them to switch. So what
    do people think?

    Honza


    \
     
     \ /
      Last update: 2012-04-24 18:45    [W:4.481 / U:0.656 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site