lkml.org 
[lkml]   [2005]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-04-06 13:31    [W:0.290 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site