> Yeah, sorry ... I guess someone should have published the phone
> conversation we had yesterday ... </me pokes Dave in the eye>
>
> We came to the conclusion that should be adding the semaphore to the
> current code even, as list_add_tail isn't atomic to a doubly linked list
> (unless maybe you can do some fancy-pants compare and exchange thing
> after setting up the prev pointer of the new element already). Which is
> probably going to suck performance-wise, but I'd prefer correctness. From
> there we can make a better judgment, but it sounds like it's going to
> content horribly on those busy semaphores.
I didn't publish the conversation because I realized that the semaphore is
taken outside the function, so it is held. It's what I called you back to
tell you.
I'm guessing the contention we're seeing with Hugh's fix is because of the
way ld.so works. It maps the entire library, then does an mprotect to
change the idata section from shared to private. It does this for every
mapped library after every exec.
Dave
======================================================================
Dave McCracken IBM Linux Base Kernel Team 1-512-838-3059
dmccr@us.ibm.com T/L 678-3059
-
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/