RE: [Ext-rt-dev] Re: [ANNOUNCE] Linux 2.6 Real Time Kernel

From: Thomas Gleixner (tglx_at_linutronix.de)
Date: 10/12/04

  • Next message: Pavel Machek: "Re: [Patch 2/5] xbox: disable optimization for kernel decompressor"
    To: Sven Dietrich <sdietrich@mvista.com>
    Date:	Tue, 12 Oct 2004 22:37:00 +0200
    
    

    On Tue, 2004-10-12 at 22:31, 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);
    > >
    > > 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.

    Yup, and having a unique identifiable thing for all that stuff in the
    code would make life easier for coders and for people who want to
    experiment and change things.

    > 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).

    Ok, will try to make it work on more than two files and two patterns.

    Any preferences on scripting language ?

    tglx

    -
    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: Pavel Machek: "Re: [Patch 2/5] xbox: disable optimization for kernel decompressor"

    Relevant Pages

    • RE: [Ext-rt-dev] Re: [ANNOUNCE] Linux 2.6 Real Time Kernel
      ... > If there is the tendency to touch the concurrency controls in general ... expanding on the existing sequence starting with PREEMPT, IRQ_THREADS, ... but I think in general this type of script would not be a bad addition ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [ANNOUNCE] kpatchup 0.02 kernel patching script
      ... First of all, very nice script. ... it doesn't look like it properly handles empty directories. ... list index out of range ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Versioning of tree
      ... I was unable to find a way to force the script to be run before ... I thought perl was already used somewhere intrinsically during a build. ... and simply use a hash on it, then take a substring of the hash to get a ... 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/ ...
      (Linux-Kernel)
    • Re: git-pull-script on my linus tree fails..
      ... > but I haven't touched that tree so I shouldn't get merge issues.. ... I guess I can make the "git pull" script do that automatically (some other ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [Ext-rt-dev] Re: [ANNOUNCE] Linux 2.6 Real Time Kernel
      ... Sven Dietrich wrote: ... >>If there is the tendency to touch the concurrency controls in general ... then I would suggest a script driven overhaul of ... > expanding on the existing sequence starting with PREEMPT, IRQ_THREADS, ...
      (Linux-Kernel)