Messages in this thread | | | Date | Sun, 5 Jun 2005 10:54:49 +0200 (METDST) | From | Esben Nielsen <> | Subject | Re: [patch] Real-Time Preemption, plist fixes |
| |
On Sun, 5 Jun 2005, Ingo Molnar wrote:
> * Thomas Gleixner <tglx@linutronix.de> wrote: > > > + * (C) 2005 Thomas Gleixner <tglx@linutronix.de> > > + * Tested and made it functional. I'm still pondering if it is > > + * worth the trouble. > > you had a long Saturday night debugging session i guess: > > > Date: Sun, 05 Jun 2005 02:17:12 +0200 > > but i think the fundamental question remains even on Sunday mornings - > is the plist overhead worth it? Compared to the simple sorted list we > exchange O(nr_RT_tasks_running) for O(nr_RT_levels_used) [which is in > the 1-100 range], is that a significant practical improvement? By > overhead i dont just mean cycle cost, but also architectural flexibility > and maintainability. > Sorted lists works deterministicly O(1) on UP if no owner of the lock blocks while having the lock. On SMP or worse if an owner blocks in the lock, the wait list can grow very long. Thus insertion of new elements takes a long time - with preemption disabled :-(
If this is supposed to be used for user-space PI as well I would say it would have to be completely bounded, i.e. plists are certainly needed. If it is in the kernel only, you might argue that the code is under control and thus not make very long wait-lists. Therefore it is not worth the extra CPU cycles to use them. However, there is no way to know for sure. In extreme load situations we could end up with a lot of waiters on mmap_sem forinstance.
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/
| |