Re: RT patch acceptance

From: Paulo Marques (pmarques_at_grupopie.com)
Date: 06/01/05

  • Next message: david.balazic_at_hermes.si: "Swap maximum size documented ?" 
    Date:	Wed, 01 Jun 2005 13:18:54 +0100
To: Andrea Arcangeli <andrea@suse.de>

    Andrea Arcangeli wrote:
    >[...]
    > Plus with RTAI we don't depend on scheduler to do the right thing etc...
    > that suff can break when somebody tweak the scheduler for some smp
    > scalability bit or something like that (just watch currently Linus and
    > Ingo going after a scheduler bug that hangs the system, that would crash
    > a system with preempt-RT but RTAI would keep going without noticing
    > since it gets irq even when irqs are locally disabled), while it sounds
    > harder to break the nanokernel thing that depends on hardware feature
    > and unmaskable irqs.

    It seems you didn't follow that thread too closely :)

    The problem on that thread is that most of the processes running on the
    system have the same priority, and the way wine works is giving it an
    interactive priority bonus that makes it run preferentially over other
    processes with the "same" priority.

    This wouldn't affect real-time tasks running over preempt-RT at all,
    since the interactive bonus would never be enough to go over real-time
    priority tasks.

    I do understand the point you're trying to make about the simplicity of
    a nano-kernel that makes it much more reliable and verifiable.

    However it seems that the range of applications that can use the
    nano-kernel approach is getting pretty thin between the applications
    that are so simple that they can run on a dedicated hardware/processor
    without any OS at all, and the applications that require more complex
    services than those that a nanokernel can provide by itself. 

    -- 
Paulo Marques - www.grupopie.com
An expert is a person who has made all the mistakes that can be
made in a very narrow field.
Niels Bohr (1885 - 1962)
-
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/
  • Next message: david.balazic_at_hermes.si: "Swap maximum size documented ?"

    Relevant Pages

    • Re: Where is RLIMIT_RT_CPU?
      ... average) more CPU than they would get running at normal priority. ... most audio applications tend to only ... the higher priority one leaves enough cpu for the lower priority one. ... That solution doesn't need anything added into the scheduler. ...
      (Linux-Kernel)
    • Re: RFC for a new Scheduling policy/class in the Linux-kernel
      ... B is holding a lock. ... A grants its priority B until B releases the lock. ... We want to charge B's critical section to B, ... scheduler computes how much time A has used recently, ...
      (Linux-Kernel)
    • [RFC][PATCH] O(1) Entitlement Based Scheduler
      ... This patch is a modification of the Oscheduler that introduces ... _entitlement_ to CPU resources that is determined by the number of _shares_ ... This patch provides both soft and hard CPU usage rate caps per ... one getting the most can be given a better priority, ...
      (Linux-Kernel)
    • Re: RFC for a new Scheduling policy/class in the Linux-kernel
      ... A grants its priority B until B releases the lock. ... We want to charge B's critical section to B, ... spent while holding locks. ... scheduler computes how much time A has used recently, ...
      (Linux-Kernel)
    • Re: Renice X for cpu schedulers
      ... (That's all that any of these dynamic priority heuristics ... really seem to do -- weight the scheduler towards switching to ... the design _intent_; but I think it's fairly accurate in terms of the ... non-threaded design of the X server makes it ...
      (Linux-Kernel)
    Loading