On Mon, Jun 20, 2011 at 9:13 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> Er... The current mainline does atomic_read() followed by atomic_inc(),
> so we get the same thing (plus the spin_lock()/spin_unlock()), don't we?
Yes. Unless the spinlock is in the same cacheline. No reason not to
fix that, though.
Of course, if the "ETXTBUSY" case is the common case (which I doubt),
then not doing the write at all would be the optimal case. But I doubt
that case is even worth really worrying about ;)
> For get_write_access() it's probably the right assumption for everything but
> /dev/tty*; for deny_write_access() it's not - a lot of binaries are run by
> more than one process...
Note the fact that EVEN IF WE GUESS INCORRECTLY, performance is likely
better by guessing rather than reading, unless you know the thing is
already in the local CPU cache.
Doing the loop twice instead of once is still *much* faster than an
extra cache transaction that goes to the bus (or L3 or whatever).
> FWIW, I wonder what will the things look like on ll/sc architectures;
There are no ll/sc architectures worth worrying about, so I don't
think that's the primary concern. That said, I don't disagree with
creating a "atomic_inc_unless_negative()" helper.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
