lkml.org 
[lkml]   [2006]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: New PriorityInheritanceTest - bug in 2.6.17-rt7 confirmed
    From
    On Thu, 6 Jul 2006, Thomas Gleixner wrote:

    > On Thu, 2006-07-06 at 14:07 +0100, Esben Nielsen wrote:
    >> So this is a real bug.
    >
    > True
    >
    >> In the previous mail I posted a fix for that problem (and other problems).
    >
    > I had not much time to look at the patch, but I doubt that we need such
    > a complex hack to achieve that. I will look at it later.

    The problem is that the deboosting code have to run somewhere.
    It can run within try_to_wake_up(). But then it the whole lock chain is
    traversed in an atomic section. That unpredictable overall system
    latencies since the locks can be in userspace.
    So it has to run in some task. That task has to be high priority enough
    to preempt the boosted tasks, but it can't be so high priority that it bothers
    any higher priority threads than those involved in this. So it can't be,
    forinstance a general priority 99 task we just use for this. We thus need
    something running at a slightly higher priority than the priority to
    which the tasks are boosted, but not a full +1 priority. I.e. we need to
    run it at priority "+0.5".

    I also think that other stuff, like high resolution timers and others
    doing "scheduler plumbing work" in the kernel could benifit from a +0.5
    priority.

    I thought about some improvements:
    1) Make a general TSK_LIFO flag, That would remove some of the direct
    references in sched.c to the rtmutex system. In effect it will be the
    same, but be more usefull to other subsystems.
    2) Double the number of in-kernel priorities. I.e. simply add a number of
    "hidden" priorities in which this kind of "plumbing" work can be run:

    Kernel priority User space
    0 hidden
    1 RT 99
    2 hidden
    3 RT 98
    ....

    199 0
    ...

    This might turn out more clean than a TSK_LIFO. There will be no need to
    hack the core scheduler code, which can have some strange side-effect.
    But to be honest I don't think the hacks I have done are that bad - except
    they refer directly to the rtmutex subsystem. Also adding priorities would
    slow down the system.


    >
    > tglx
    >
    >

    Esben
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-07-06 15:17    [W:0.025 / U:3.544 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site