Messages in this thread | | | Date | Thu, 31 Mar 2005 15:33:25 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07 |
| |
* Steven Rostedt <rostedt@goodmis.org> wrote:
> > I was going to say the opposit. I know that there are many more rt_locks > > locks around and the fields thus will take more memory when put there but > > I believe it is more logical to have the fields there. > > It seems logical to be there, but in practicality, it's not. > > The problem is that the flags represent a state of the task with > respect to a single lock. When the task loses ownership of a lock, > the state of the task changes. But the the lock has a different state > at that moment (it has a new onwner). Now when it releases the lock, > it might give the lock to another task, and that becomes the pending > owner. Now the state of the lock is the same as in the beginning. But > the first task needs to see this change. > > You can still pull this off by testing the state of the lock and > compare it to the current owner, but I too like the fact that you > don't increase the size of the kernel statically. There are a lot > more locks in the kernel than tasks on most systems. And those systems > that will have more tasks than locks, need a lot of memory anyway. So > we only punish the big systems (that expect to be punished) and keep > the little guys safe.
no system is punished. Since task_struct embedds 2 locks already, moving the field(s) into task_struct is already a win.
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/
| |