Re: [test result] dirty logging without srcu update -- Re: [RFC][PATCH]srcu: Implement call_srcu()

[Avi Kivity]

On 02/02/2012 12:21 PM, Takuya Yoshikawa wrote:
> (2012/02/02 19:10), Avi Kivity wrote:
>
>>>
>>> =========================================================
>>> # of dirty pages:  kvm.git (ns),  with this patch (ns)
>>> 1:         102,077 ns      10,105 ns
>>> 2:          47,197 ns       9,395 ns
>>> 4:          43,563 ns       9,938 ns
>>> 8:          41,239 ns      10,618 ns
>>> 16:         42,988 ns      12,299 ns
>>> 32:         45,503 ns      14,298 ns
>>> 64:         50,915 ns      19,895 ns
>>> 128:        61,087 ns      29,260 ns
>>> 256:        81,007 ns      49,023 ns
>>> 512:       132,776 ns      86,670 ns
>>> 1024:      939,299 ns     131,496 ns
>>> 2048:      992,209 ns     250,429 ns
>>> 4096:      891,809 ns     479,280 ns
>>> 8192:    1,027,280 ns     906,971 ns
>>> (until now pretty good)
>>>
>>> (ah, for every 32-bit atomic clear mask ...)
>>> 16384:   1,270,972 ns   6,661,741 ns    //  1  1  1 ...  1
>>> 32768:   1,581,335 ns   9,673,985 ns    //  ...
>>> 65536:   2,161,604 ns  11,466,134 ns    //  ...
>>> 131072:  3,253,027 ns  13,412,954 ns    //  ...
>>> 262144:  5,663,002 ns  16,309,924 ns    // 31 31 31 ... 31
>>> =========================================================
>>
>> On a 64-bit host, this will be twice as fast.  Or if we use cmpxchg16b,
>> and there are no surprises, four times as fast.  It will still be slower
>> than the original, but by a smaller margin.
>
> Yes.
>
> I used "unsigned int" just because I wanted to use the current
> atomic_clear_mask() as is.
>
> We need to implement atomic_clear_mask_long() or use ...

If we use cmpxchg8b/cmpxchg16b then this won't fit with the
atomic_*_long family.

-- 
error compiling committee.c: too many arguments to function

--
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/