[lkml]   [2003]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: softirqd
    On Mon, 17 Nov 2003, kernwek jalsl wrote:

    > Hi All;
    > On my embedded board I see that the preemption
    > patch(Love etal.) is not of much use because of the
    > following reaons:
    > 1) calling the scheduler after the hardirq returns is
    > not of much use because the actual work of puting the
    > task in the run queue is done in the bottom half
    > executed by ksoftirqd
    > 2) ksoftirqd is not a real time thread
    > Will the preemption patch work better if the ksoftirqd
    > is made a real time thread?
    > Another related question : has anyone thought of
    > introducing prioirty among tasklets? Right now
    > ksoftirqd treats them in a FIFO manner. Adding
    > priority among the various tasklets and making sure
    > that ksoftirqd looks ahead in the queue would ensure a
    > real time treatment to a real time interrupt...

    What is the problem that you are attempting to fix?
    Stating that x is not y does not mean anything useful.
    'Real-time' related to an 'interrupt' has no meaning.

    An interrupt occurs as soon as hardware demands it.
    The software response to that interrupt, i.e., interrupt-
    latency is dependent upon the ISR setup code in the
    kernel plus the execution time of any higher-priority
    interrupts that may be occurring plus the execution time
    of any prior code sharing the same interrupt. By the time
    your ISR code gets control, the time is bounded by some
    worse-case execution times and real-time has no meaning.

    Then your ISR code must handle the immediate requirements
    of the hardware as fast and efficiently as possible. Things
    that can be deferred may be handed over to the soft-IRQ
    stuff. If you have things that can't be deferred, you must
    not do it in the soft-IRQ (used to be called bottom-half)

    Specifically, the things that can be handled in a soft-IRQ
    are hardware configuration changes and such where here are
    no deadlines. If you have deadlines, i.e., you must get
    the data out of a device now before it gets overwritten by
    new data, then it must be done in the top-half handler.

    Also, If you ever enable interrupts in your ISR, plan that
    the CPU __will__ get taken away. It may be hundreds of
    milliseconds before your ISR ever gets the CPU again. It
    all depends upon the behavior of other drivers and some
    network drivers even loop inside their ISR. Once they get
    control, you may not get the CPU until a break in network

    In the context of a multi-user time-share operating system,
    "real-time" means "fast enough". If your complete system can
    keep up with the demands of these external events without
    ever losing data, then it is "real-time". However, you can't
    use these kinds of systems (fast-enough systems) in closed
    servo-loops because the time from an interrupting event to
    the completion of the necessary response to that event is
    not known. For those kinds of "real-time" systems, you need
    a "real-time kernel". Real-time kernels define the poles in
    the system transfer-function so that the delay is known and
    bounded within strict limits. Such systems are not "better".
    In fact, they might be much slower in response to the usual
    requirements for interactivity.

    Realtime kernels do this by scheduling on strict time-boundaries.

    Dick Johnson
    Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
    Note 96.31% of all statistics are fiction.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:58    [W:0.023 / U:45.628 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site