Re: [patch] voluntary-preempt-2.6.8-rc2-J3

From: Eric St-Laurent (ericstl34_at_sympatico.ca)
Date: 07/30/04

  • Next message: David S. Miller: "Re: tcp_push_pending_frames() without TCP_CORK or TCP_NODELAY" 
    To: Ingo Molnar <mingo@elte.hu>
Date:	Thu, 29 Jul 2004 22:31:07 -0400

    On Mon, 2004-07-26 at 16:36, Ingo Molnar wrote:
    > one alternative technique to yours would be to notify _all_ CPUs that a
    > high-prio RT task is ready to run (via a broadcast need-resched). That
    > way the UP latency-break techniques map to SMP in a 1:1 way.
    >
    > non-RT tasks dont get this benefit, which is a difference to the UP
    > situation, but i dont think it would be appropriate to use the UP
    > behavior, due to the overhead of broadcasting.
    >
    > a combination of the two techniques could be used too: a global 'break
    > locks from now on' flag which gets set if a (RT?) task wants to
    > reschedule. Normally this flag would be zero and the cacheline would be
    > clean and shared between all CPUs, causing no overhead. Once a task

    It might be possible to eliminate the need_resched flag. Here is an
    article that talk about a event-driven preemption model.

    Quoting :

    Over the long term, MontaVista is investigating whether preemption locks
    can be eliminated (or at least greatly reduced in number) by protecting
    all the short-duration critical regions with spinlocks that also disable
    interrupts on the local CPU, and the long-duration critical regions with
    mutex locks. ("Long duration" means much greater than the time taken by
    two context switches.) This will reduce the overhead of the preemptable
    kernel, since there will no longer be any need to test for preemption
    ("polling for preemption") at the end of a preemption-locked region
    (which could happen tens of thousands of times per second on an average
    system). Instead, preemption would happen automatically as part of the
    interrupt servicing that causes a higher-priority process to become
    runnable ("event-driven preemption"). Typically, this only happens a few
    times to a few tens of times per second with an average system workload,
    making the "event-driven preemption" model much more efficient than the
    "polling for preemption" model. This method also has an added efficiency
    in that the system will take advantage of the cache disruption caused by
    the interrupt (which is unavoidable) to continue with the preemption.

    Reference:

    http://www.linuxdevices.com/cgi-bin/printerfriendly.cgi?id=AT4185744181

    Best regards,

    Eric St-Laurent

    -
    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 S. Miller: "Re: tcp_push_pending_frames() without TCP_CORK or TCP_NODELAY"

    Relevant Pages

    • Re: cooperative multitasking scheme
      ... >>The basic essence of preemption is that there must be some method by which the ... >software interrupt, thus the interrupt handler can be nearly identical ... That's cooperation. ... The software interrupt is nothing more than a call which is ...
      (comp.arch.embedded)
    • Re: What is the PREEMPTION option good for?
      ... I found another setup where PREEMPTION help -- nfs servers. ... give correct scheduling of interrupt threads, and that seems to be all ... FULL_PREEMPTION is apparently needed to get kernel threads preempted by ...
      (freebsd-arch)
    • Re: bge dropping packets issue
      ... But why was it added to begin with if standard interrupt driven I/O is ... than 150 usec), so 512 descriptors is more than enough for 1Gbps ethernet ... (the minimum possible inter-descriptor time for tiny packets is about 0.6 ... PREEMPTION so that lower-priority interrupt handlers like ata and sc get ...
      (freebsd-net)
    • [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
      ... i have released the -V0.7.25-0 Real-Time Preemption patch, ... new features and latency improvements. ... the biggest change is the threading of the lone remaining non-threaded ... external interrupt: the timer interrupt. ...
      (Linux-Kernel)
    • Re: What is the PREEMPTION option good for?
      ... suspiciously active on heavy loaded SMP web servers (even complained on ... I'll try disabling PREEMPTION and see how it goes. ... to RELENG_4 for interrupt latency. ... interrupt priorities don't work right -- ...
      (freebsd-arch)