We =have= a fast MUTEX already. It's the semaphore code.
All the code you're looking at is almost completely uninteresting for
performance handling: by the time the code is invoced you've already had
contention on the semaphore, and you just need to make sure that you get
the right result.
And even if that code ever becomes a bottle-neck, the right approach is
NOT to make it all that much faster: the right approach is to make sure
that the semaphore that gets tons of contention is fixed up.
So I want the semaphores to be stable and simple, because the fast path
has already been done somewhere else.
I agree with your wake-one semantic issue, but I disagree with just about
all of the other changes.
> Does somebody knows a place that uses the semaphores initialized with a
> count > 1 ? I don't.
So?
> Supposing the seamphores are mutex you have two choices in down_trylock():
You have one choice: fix things up. It already failed, there's no point in
doing anything else.
We tried to be clever before. There was absolutely no data that it was
ever a win, and there were lots of indications that it was buggy. Let's
not make that mistake again. Don't optimize code that doesn't need
optimization.
Btw, the case you optimize for is the case that is supposed to be
_extremely_ rare even in the presense of contention. You optimize not just
for the contention-case, you optimize for the specific case where the
values are racing and changing on different CPU's at the same time. Do you
_really_ think that it is worth it, considering that you make the
semaphore behaviour more complex?
I really don't.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/