Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6

From: Esben Nielsen (simlo_at_phys.au.dk)
Date: 12/11/04

  • Next message: Adam Heath: "Re: Concurrent access to /dev/urandom" 
    Date:	Sat, 11 Dec 2004 20:50:43 +0100 (MET)
To: Steven Rostedt <rostedt@goodmis.org>

    On Sat, 11 Dec 2004, Steven Rostedt wrote:

    > On Sat, 2004-12-11 at 18:59 +0100, Esben Nielsen wrote:
    > > On Fri, 10 Dec 2004, Steven Rostedt wrote:
    >
    > > I am not sure I understand you correctly.
    > >
    > > If it is a general method of making priority sorting on wait-queues: Yes,
    > > certainly! The highest priority task nearly always ought to be woken
    > > first.
    > >
    > > But in a lot of cases you send messages from high to low and visa verse
    > > without wanting to move their priorities by doing so. If forinstance you
    > > want a IRQ-thread to be increased in priority when a RT task listens to
    > > packets from that device I think it is a bad idea. The developer should
    > > himself set the priorities right. The device might use a lot of CPU in
    > > some cases. By increasing it's priority you might destroy the RT
    > > properties of all the tasks in between. In general you don't know.
    > >
    >
    > Actually, I was thinking of something more configurable (and so, more
    > complex). The main problem I've seen in general, is to differentiate
    > services for RT tasks and others. So if a RT task is waiting for some
    > disk activity while other RT tasks are running, the IRQ thread (or
    > whatever will service the disk) may be starved. I agree that this is
    > really more of a design issue, but I thought that there may be ways to
    > facilitate the RT design by setting flags in a task before it reads from
    > disk, so in case the RT task blocks waiting for a disk read, the disk
    > serving thread would inherit the priority of that task. One could argue
    > that the task could simply increase the service provider's priority
    > before doing the read, but than it may not block, and this would be a
    > waist.

    Disk access - at least on top of a filesystem - is not real-time. But we
    can say it is some other device.

    I would take the following approach:
    1) Ensure the IRQ handler isn't in anyway using a too much CPU and
    increase it's priority staticly.
    2) Reconsider my overall design: Apparently the device isn't suit-able for
    real-time.

    >
    > I guess servicing in general is very hard to predict, so a RT task must
    > have all its information read and stored somewhere that it can receive
    > in a predictable amount of time, and not on disk or someplace that takes
    > another task to do the request that handles other tasks as well (thus
    > complicating the priority scheme). As for sockets, I did my Master's
    > thesis on setting up RT sockets that are handle separately from other
    > sockets with a protocol that allows for incoming packets to quickly be
    > determined that they are RT packets and can go right to where they are
    > needed.

    Linux relies on soft IRQ for delivering packets to the listening
    protocol stacks. That is a problem because you can't just boost the
    priority of soft-IRQ without boosting a lot of things.

    With IRQ-threading the design could be changed such the IRQ thread does
    the job directly. But that will make the whole IRQ thread drive the
    protocol stack as well :-(

    It all depends on what your requirements are. Maybe you can handle
    "driving" the whole IP stack before handling the RT packet - maybe not.

    How did you handle it in your thesis?

    >
    > I just wanted to bring up this discussion, I guess a general approach is
    > too difficult and not worth the effort.
    >

    If you can think up something there is no harm in trying it :-)
     
    > Thanks,
    >
    > -- Steve
    >
    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/

  • Next message: Adam Heath: "Re: Concurrent access to /dev/urandom"

    Relevant Pages

    • Re: Scheduler: Process priority fed back to parent?
      ... Mac OS X has a special cache ... on disk of things that get loaded on boot. ... >>initial priority is a guess, and isn't set until the priority info has ... This prefetch activity could be turned on/off ...
      (Linux-Kernel)
    • Re: Scheduler: Process priority fed back to parent?
      ... There would have to be some sort of cache. ... > The kernel already does disk access to load a process... ... > would be an artificial one which always exists for this, or the priority ...
      (Linux-Kernel)
    • Re: *The* definition of assembly langauge
      ... I did not see anything like a disk scan and the effect was like ... BitBlt would place the full image size of your app at something over ... If its a priority setting, try high rather than realtime as it allows ... Data alignment makes sense but I have seen little reason to exceed 16 ...
      (alt.lang.asm)
    • Re: [PATCH] O13int for interactivity
      ... > a process that isn't a CPU hog? ... Disk IO aside, ... improve it's dynamic priority by 5". ... hog never sleeps intentionally and the estimator sees this as "I'm a ...
      (Linux-Kernel)
    • Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
      ... The highest priority task nearly always ought to be woken ... > packets from that device I think it is a bad idea. ... whatever will service the disk) may be starved. ... As for sockets, I did my Master's ...
      (Linux-Kernel)