[lkml]   [2011]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.39-rc4+: Kernel leaking memory during FS scanning, regression?
    On Wed, Apr 27, 2011 at 3:32 PM, Thomas Gleixner <> wrote:
    > Well that's going to paper over the problem at hand possibly. I really
    > don't see why that thing would run for more than 950ms in a row even
    > if there is a large number of callbacks pending.

    Stop with this bogosity already, guys.

    We _know_ it didn't run continuously for 950ms. That number is totally
    made up. There's not enough work for it to run that long, but more
    importantly, the thread has zero CPU time. There is _zero_ reason to
    believe that it runs for long periods.

    There is some scheduler bug, probably the rt_time hasn't been
    initialized at all, or runtime we compare against is zero, or the
    calculations are just wrong.

    The 950ms didn't happen. Stop harping on it. It almost certainly
    simply doesn't exist.

    Since that

    if (rt_rq->rt_time > runtime) {
    rt_rq->rt_throttled = 1;
    + printk_once(KERN_WARNING "sched: RT throttling activated\n");

    test triggers, we know that either 'runtime' or 'rt_time' is just
    bogus. Make the printk print out the values, and maybe that gives some

    But in the meantime, I'd suggest looking for the places that
    initialize or calculate those values, and just assume that some of
    them are buggy.

    > And then I don't have an explanation for the hosed CPU accounting and
    > why that thing does not get another 950ms RT time when the 50ms
    > throttling break is over.

    Again, don't even bother talking about "another 950ms". It didn't
    happen in the first place, there's no "another" there either.


     \ /
      Last update: 2011-04-28 01:31    [W:0.022 / U:8.544 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site