Re: [patch] IRQ threads

From: Karim Yaghmour (karim_at_opersys.com)
Date: 07/28/04

  • Next message: Eric W. Biederman: "Re: [Fastboot] Re: Announce: dumpfs v0.01 - common RAS output API" 
    Date:	Wed, 28 Jul 2004 11:45:28 -0400
To: Scott Wood <scott@timesys.com>

    Scott Wood wrote:
    > I have attached a patch for implementing IRQ handlers in threads, for
    > latency-reduction purposes. It requires that softirqs must be run in
    > threads (or else they could end up running inside the IRQ threads,
    > which will at the very least trigger bugs due to in_irq() being set).
    > I've tested it with Ingo's voluntary-preempt J7 patch, and it should
    > work with the TimeSys softirq thread patch as well (though you might
    > get a conflict with the PF_IRQHANDLER definition; just merge them
    > into one).

    My experience with clients who have been using TimeSys' stuff has been
    abysmal. The fact of the of the matter is that most people who used
    this were practically locked-in to TimeSys' services, unable to download
    anything "standard" off the net and using it with their kernel. In one
    example, we had to ditch the kernel the client got from TimeSys because
    we had spent 10+ hours trying to get LTT to work on it without any
    success whatsoever.

    As I had said on other lists before, I don't see the point of creating
    that much complexity in the kernel in order to try to shave-off a little
    bit more off of the kernel's interrupt response time. The fact of the
    matter is that neither this patch nor most of the other patches suggested
    makes the kernel truely hard-rt. These patches only make the kernel
    respond "faster". If you really need hard-rt, then you should be using
    the Adeos nanokernel. With Adeos, you can even get a hard-rt driver
    without using RTAI or any of the other rt derivatives.

    Karim 

    -- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546
-
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: Eric W. Biederman: "Re: [Fastboot] Re: Announce: dumpfs v0.01 - common RAS output API"

    Relevant Pages

    • Re: [patch] IRQ threads
      ... > this were practically locked-in to TimeSys' services, ... > that much complexity in the kernel in order to try to shave-off a little ... > matter is that neither this patch nor most of the other patches suggested ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: RT patch acceptance
      ... judge the complexity of a design for that type of system. ... claim that you cannot judge the complexity of a kernel modification. ... Since the patch in question doesn't actually need that information to ... nanokernel's API up to date with additions to Linux's API that RT people ...
      (Linux-Kernel)
    • Re: inline asm semantics: output constraint width smaller than input
      ... Now in this case the patch you suggest might end up hurting the end result ... The below patch is to build the kernel for x86_64, ... # Device Drivers ... # PCI IDE chipsets support ...
      (Linux-Kernel)
    • [RFC] Making percpu module variables have their own memory.
      ... Someone using the -rt patch found that one of the tracing options caused ... 64K for every CPU to cover all the per_cpu variables used in the kernel ... static void wakeup_softirqd_prio ...
      (Linux-Kernel)
    • Re: This is [Re:] How to improve the quality of the kernel[?].
      ... The -mm kernel already implements what your proposed PTS would do. ... If patch have no TS ID, ... Thus i can apply for example lguest patches and implement and test new ... How many open source projects use Bugzilla and how many use the Debian BTS? ...
      (Linux-Kernel)