Re: [PATCH v7 1/4] qrwlock: A queue read/write lock implementation

[Linus Torvalds]

On Fri, Nov 22, 2013 at 12:35 PM, Waiman Long <waiman.long@xxxxxx> wrote:
>
> Yes, the extra latency of the fair lock in earlier patch is due to the need
> to do a second cmpxchg(). That can be avoided by doing a read first, but
> that is not good for good cache.  So I optimized it for the default unfair
> lock. By supporting only one version, there is no need to do a second
> cmpxchg anymore.

Ok, thanks.

> I reran the timing test on the 2.93GHz processor. The timing is the
> practically the same. I reused the old one for the 2.4GHz processor.

Sounds good. I just wanted to make sure the numbers were sane.

            Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/