lkml.org 
[lkml]   [2004]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [ANNOUNCE] Linux 2.6 Real Time Kernel
    Date

    I think Daniel has some separate thoughts,
    here are mine:

    Regarding the list walking stuff:

    There are a lot of hashing options, indexing,
    etc. that could be done. We thought of it
    as a future optimization. An easy fix would
    be to insert RT processes at the front, non-RT
    from the tail of the queue.


    Regarding patch size: clearly this is
    an issue. We are working on creating a
    good map of spinlock nestings, to help
    with this.

    Will publish that ASAP.


    IMO the number of raw_spinlocks should be
    lower, I said teens before.

    Theoretically, it should only need to be
    around hardware registers and some memory maps
    and cache code, plus interrupt controller
    and other SMP-contended hardware.

    Practically, its an efficiency judgement call.
    Its not worth blocking for 5 instructions in
    a critical section under any circumstance,
    so the deepest nested locks should probably remain
    spinlocks.

    There are some concurrency issues in kernel threads,
    and I think there is a lot of work here.
    The abstraction for LOCK_OPS is a good alternative,
    but like the spin_undefs, its difficult to tell
    in the code whether you are dealing with a mutex
    or a spinlock.

    Regarding the use of the system semaphore:
    We have WIP on PMUTEX modified to use atomic_t,
    thereby eliminating the assembly for instant
    portability.

    Its slow, but optimizations are allowed for.

    Of course for actual portability the
    IRQ threads must also be running on those
    other platforms.

    Your IRQ abstraction is ideal for that.

    Eventually, I think that we will see
    optimization - the last touches would have
    the final mutex code converted back to
    assembly, for performance reasons.

    There are a whole lot of caveats and race
    conditions that have not yet been unearthed
    by the brief LKML testing. A lot of them
    have to do with wakeups of tasks blocked
    on a mutex, and differentiating between
    blocked "ready" and blocked "mutex" states.
    Here the system semaphore may have an advantage.

    With that, maybe we can work back towards
    the abstraction, so that we can evaluate both
    solutions for their specific advantages.

    I'll have to take a look at the new T4 patch
    in detail, but at first glance it seems
    that both mutexes could coexist in the
    abstraction.

    We'll give it a test run, and look forward to
    your thoughts.

    Thanks,

    Sven


    > -----Original Message-----
    > From: Ingo Molnar [mailto:mingo@elte.hu]
    > Sent: Monday, October 11, 2004 1:50 PM
    > To: Daniel Walker
    > Cc: Andrew Morton; sdietrich@mvista.com; linux-kernel@vger.kernel.org;
    > abatyrshin@ru.mvista.com; amakarov@ru.mvista.com; emints@ru.mvista.com;
    > ext-rt-dev@mvista.com; hzhang@ch.mvista.com; yyang@ch.mvista.com
    > Subject: Re: [ANNOUNCE] Linux 2.6 Real Time Kernel
    >
    >
    >
    > * Daniel Walker <dwalker@mvista.com> wrote:
    >
    > > On Sun, 2004-10-10 at 14:59, Ingo Molnar wrote:
    > > > * Andrew Morton <akpm@osdl.org> wrote:
    > > >
    > > > > Lockmeter gets in the way of all this activity in a big way. I'll
    > > > > drop it.
    > > >
    > > > great. Daniel, would you mind to merge your patchkit against the
    > > > following base:
    > > >
    > > > -mm3, minus lockmeter, plus the -T3 patch
    > >
    > >
    > > No problem. Next release will be without lockmeter. Thanks for the
    > > patches.
    >
    > what do you think about the PREEMPT_REALTIME stuff in -T4? Ideally, if
    > you agree with the generic approach, the next step would be to add your
    > priority inheritance handling code to Linux semaphores and
    > rw-semaphores. The sched.c bits for that looked pretty straightforward.
    > The list walking is a bit ugly but probably unavoidable - the only other
    > option would be 100 priority queues per semaphore -> yuck.
    >
    > Ingo
    >
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:06    [W:0.040 / U:187.756 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site