[resend: i fat fingered the reply-to-all for a few messages] >>> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 01/07/09 6:20 PM >>> >On Wed, 7 Jan 2009, Linus Torvalds wrote: >> > >> > "Is get_task_struct() really that bad?" >> >> Yes. It's an atomic access (two, in fact, since you need to release it >> too), which is a huge deal if we're talking about a timing-critical >> section of code. > >There's another issue: you also need to lock the thing that gives you the >task pointer in the first place. So it's not sufficient to do >get_task_struct(), you also need to do it within a context where you know >that the pointer is not going away _while_ you do it. In my defense, the -rt versions of the patches guarantee this is ok based on a little hack: "if the owner holds the mutex, and you old the wait-lock, you guarantee owner cannot exit". Therefore get_task_struct is guaranteed not to race if you take it while holding wait-lock. (This is, in fact, why the original design had a loop within a loop...the inner loop would break when it wanted the outer-loop to reacquire wait-lock for things such as re-acquiring owner/get-task This is in part enforced by the fact that in -rt, pending pending waiters force the mutex-release to hit the slow path (and therefore require that the wait-lock be reacquired by the releaser). I am under the impression (because I havent had a chance to really review the new patches yet) that this is not necessarily the case here for the mainline patch, since the owner field is not managed atomically IIUC Again, not advocating get/put task per se. Just wanted to point out that I didnt flub this up on the original -rt design ;) -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
