Messages in this thread | | | Subject | RE: [Ext-rt-dev] Re: [ANNOUNCE] Linux 2.6 Real Time Kernel | From | Thomas Gleixner <> | 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/
| |