All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
Cc: Peter Zijlstra <peterz@infradead.org>,
	paulmck@linux.vnet.ibm.com, Oleg Nesterov <oleg@redhat.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	KVM list <kvm@vger.kernel.org>
Subject: Re: [test result] dirty logging without srcu update -- Re: [RFC][PATCH] srcu: Implement call_srcu()
Date: Thu, 02 Feb 2012 12:21:58 +0200	[thread overview]
Message-ID: <4F2A63C6.7030301@redhat.com> (raw)
In-Reply-To: <4F2A63B9.8000405@oss.ntt.co.jp>

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

  reply	other threads:[~2012-02-02 10:21 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-31 13:32 [RFC][PATCH] srcu: Implement call_srcu() Peter Zijlstra
2012-01-31 13:47 ` Avi Kivity
2012-01-31 13:50   ` Peter Zijlstra
2012-01-31 22:24     ` Paul E. McKenney
2012-02-01 10:22       ` Peter Zijlstra
2012-02-01 10:44         ` Avi Kivity
2012-02-01 10:49           ` Avi Kivity
2012-02-01 11:00             ` Takuya Yoshikawa
2012-02-01 11:01               ` Avi Kivity
2012-02-01 11:12                 ` Takuya Yoshikawa
2012-02-01 13:24                   ` Avi Kivity
2012-02-02  5:46                     ` [test result] dirty logging without srcu update -- " Takuya Yoshikawa
2012-02-02 10:10                       ` Avi Kivity
2012-02-02 10:21                         ` Takuya Yoshikawa
2012-02-02 10:21                           ` Avi Kivity [this message]
2012-02-02 10:40                             ` Takuya Yoshikawa
2012-02-02 11:02                               ` Avi Kivity
2012-02-02 14:44                                 ` Takuya Yoshikawa
2012-02-02 14:57                                   ` Avi Kivity
2012-02-01 13:43                 ` Marcelo Tosatti
2012-02-01 15:42                   ` Takuya Yoshikawa
2012-02-01 13:50             ` Marcelo Tosatti
2012-02-08 15:43               ` [RFC] need to improve slot creation/destruction? -- " Takuya Yoshikawa
2012-02-08 18:45                 ` Marcelo Tosatti
2012-02-09 13:48                   ` Takuya Yoshikawa
2012-02-09 14:25                   ` Avi Kivity
2012-02-10 17:16                     ` Marcelo Tosatti
2012-02-14  9:52                       ` Avi Kivity
2012-02-09 14:23                 ` Avi Kivity
2012-02-09 14:24                   ` Avi Kivity
2012-02-10 13:08                     ` Takuya Yoshikawa
2012-02-10 17:17                       ` Marcelo Tosatti
2012-02-10 13:25                   ` Takuya Yoshikawa
2012-02-14  9:52                     ` Avi Kivity
2012-02-01 14:07         ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F2A63C6.7030301@redhat.com \
    --to=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=yoshikawa.takuya@oss.ntt.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.