[lkml]   [2004]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Ext-rt-dev] Re: [ANNOUNCE] Linux 2.6 Real Time Kernel
    Sven Dietrich wrote:
    >>>I think patch size is an issue, but I also think that , eventually, we
    >>>should change all spin_lock calls that actually lock a mutex to be more
    >>>distinct so it's obvious what is going on. Sven and I both agree that
    >>>this should be addressed. Is this a non-issue for you? What does the
    >>>community want? I don't find your code or ours acceptable in it's
    >>>current form , due to this issue.
    >>>With the addition of PREEMPT_REALTIME it looks like you more than
    >>>doubled the size of voluntary preempt. I really feel that it should
    >>>remain as two distinct patches. They are dependent , but the scope of
    >>>the changes are too vast to lump it all together.
    >>If there is the tendency to touch the concurrency controls in general
    >>all over the kernel, then I would suggest a script driven overhaul of
    >>all concurrency controls like spin_locks, mutexes and semaphores to
    >>general macros like
    >>enter_critical_section(TYPE, &var, &flags, whatever);
    >>leave_critical_section(TYPE, &var, flags, whatever);

    There is nothing here that can not be done with a macro. Don't really need a
    script. The optimizer would drop out unused code...

    >>where TYPE might be SPIN_LOCK, SPIN_LOCK_IRQ, MUTEX, PMUTEX or whatever
    >>we have and come up with in the future.
    >>This could be done in a first step and then it is clearly identifiable
    >>and it gives us more flexibility to wrap different implementations and
    >>lets us change particular points in a more clear way.
    >>I would be willing to provide some scripted conversion aid, if there is
    >>enough interest to that. I started with some test files and the results
    >>are quite encouraging.
    > Ideally we would eventually provide some level of tunability, i.e.
    > if you want the spinlocks all the way around it should be possible
    > to have that, or one could enable degrees of enhancements,
    > expanding on the existing sequence starting with PREEMPT, IRQ_THREADS,
    > BKL, MUTEX, etc. In addition to that, once the minim set of spinlocks
    > necessary for RT is established, additional layers, corresponding to
    > the lock nesting order, could be established, making the "mutex-depth"
    > somewhat configurable based on the performance requirements.
    > The entire effort would have the side effect of making the locking and
    > critical sections more distinct, and reveal soft spots in concurrency
    > code, as well as to raise awareness of the code density inside
    > critical sections.
    > The concept of tunable foreground / background responsiveness,
    > based on preemptability of low priority processes comes to mind.
    > A lot of folks would probably not mind making UI responsiveness
    > a little crisper, others will want the throughput.
    > I realize this is an early stage to be looking at it so high end,
    > but I think in general this type of script would not be a bad addition
    > to the patch kit(s).
    > Sven
    > -
    > 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

    George Anzinger
    Preemption patch:

    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 14:06    [W:0.028 / U:5.160 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site