[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 02 Feb 2012 19:21:45 +0900
From: Takuya Yoshikawa <yoshikawa.takuya@....ntt.co.jp>
To: Avi Kivity <avi@...hat.com>
CC: Peter Zijlstra <peterz@...radead.org>, paulmck@...ux.vnet.ibm.com,
Oleg Nesterov <oleg@...hat.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Marcelo Tosatti <mtosatti@...hat.com>,
KVM list <kvm@...r.kernel.org>
Subject: Re: [test result] dirty logging without srcu update -- Re: [RFC][PATCH]
srcu: Implement call_srcu()
(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 ...
>
> Yeah. But I think we should switch to srcu-less dirty logs regardless.
> Here are you numbers, but normalized by the number of dirty pages.
Thanks,
I can prepare the official patch series then, of course with more test.
Takuya
>
> dirty pages old (ns/page) new (ns/page)
> 1 102077 10105
> 2 23599 4698
> 4 10891 2485
> 8 5155 1327
> 16 2687 769
> 32 1422 447
> 64 796 311
> 128 477 229
> 256 316 191
> 512 259 169
> 1024 917 128
> 2048 484 122
> 4096 218 117
> 8192 125 111
> 16384 78 407
> 32768 48 295
> 65536 33 175
> 131072 25 102
> 262144 22 62
>
>
> Your worst case, when considering a reasonable number of dirty pages, is
> 407ns/page, which is still lower than what userspace will actually do to
> process the page, so it's reasonable. The old method is often a lot
> worse than your worst case, by this metric.
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists