lkml.org 
[lkml]   [2011]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: 2.6.32.21 - uptime related crashes?
    From
    Date
    On Fri, 2011-07-15 at 12:01 +0200, Peter Zijlstra wrote:
    > On Thu, 2011-07-14 at 17:35 -0700, john stultz wrote:
    > >
    > > Peter/Ingo: Can you take a look at the above and let me know if you find
    > > it too disagreeable?
    >
    > +static unsigned long long __cycles_2_ns(unsigned long long cyc)
    > +{
    > + unsigned long long ns = 0;
    > + struct x86_sched_clock_data *data;
    > + int cpu = smp_processor_id();
    > +
    > + rcu_read_lock();
    > + data = rcu_dereference(per_cpu(cpu_sched_clock_data, cpu));
    > +
    > + if (unlikely(!data))
    > + goto out;
    > +
    > + ns = ((cyc - data->base_cycles) * data->mult) >> CYC2NS_SCALE_FACTOR;
    > + ns += data->accumulated_ns;
    > +out:
    > + rcu_read_unlock();
    > + return ns;
    > +}
    >
    > The way I read that we're still not wrapping properly if freq scaling
    > 'never' happens.

    Right, this doesn't address the mult overflow behavior. As I mentioned
    in the patch that the rework allows for solving that in the future using
    a (possibly very rare) timer that would accumulate cycles to ns.

    This rework just really addresses the multiplication overflow->negative
    roll under that currently occurs with the cyc2ns_offset value.

    > Because then we're wrapping on accumulated_ns + 2^54.
    >
    > Something like resetting base, and adding ns to accumulated_ns and
    > returning the latter would make more sense.

    Although we have to update the base_cycles and accumulated_ns
    atomically, so its probably not something to do in the sched_clock path.

    thanks
    -john






    \
     
     \ /
      Last update: 2011-07-15 20:03    [W:0.024 / U:0.172 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site