From: Avi Kivity <avi@redhat.com>
To: OHMURA Kei <ohmura.kei@lab.ntt.co.jp>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: [Qemu-devel] Re: [PATCH 1/3] qemu-kvm: Wrap phys_ram_dirty with additional inline functions.
Date: Thu, 11 Feb 2010 14:42:33 +0200 [thread overview]
Message-ID: <4B73FB39.1000200@redhat.com> (raw)
In-Reply-To: <4B6FE5DA.6000502@lab.ntt.co.jp>
On 02/08/2010 12:22 PM, OHMURA Kei wrote:
> We think access phys_ram_dirty through inline functions is better
> than directly for encoupseling reason.
>
> We devided the ram in a 64 pages block. Each block has a counter, which is
> stored in phys_ram_dirty_by_word. It shows the number of dirty pages.
> We will find the 64 pages block is dirty or non-dirty using
> phys_ram_dirty_by_word.
>
> Signed-off-by: OHMURA Kei <ohmura.kei@lab.ntt.co.jp>
> ---
> cpu-all.h | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> cpu-defs.h | 1 +
> 2 files changed, 75 insertions(+), 0 deletions(-)
>
> diff --git a/cpu-all.h b/cpu-all.h
> index 8ed76c7..2251f14 100644
> --- a/cpu-all.h
> +++ b/cpu-all.h
> @@ -168,6 +168,33 @@ typedef union {
> } CPU_QuadU;
> #endif
>
> +static inline unsigned long unroll_flags_to_ul(int flags)
> +{
> + unsigned long ret = 0, flags_ul = (unsigned long)flags;
> +
> +#if TARGET_LONG_SIZE == 4
> + ret |= flags_ul << 0;
> + ret |= flags_ul << 8;
> + ret |= flags_ul << 16;
> + ret |= flags_ul << 24;
> +#elif TARGET_LONG_SIZE == 8
> + ret |= flags_ul << 0;
> + ret |= flags_ul << 8;
> + ret |= flags_ul << 16;
> + ret |= flags_ul << 24;
> + ret |= flags_ul << 32;
> + ret |= flags_ul << 40;
> + ret |= flags_ul << 48;
> + ret |= flags_ul << 56;
>
HOST_LONG_SIZE, not TARGET_LONG_SIZE.
> @@ -890,9 +923,50 @@ static inline int cpu_physical_memory_get_dirty(ram_addr_t addr,
>
> static inline void cpu_physical_memory_set_dirty(ram_addr_t addr)
> {
> + if (phys_ram_dirty[addr >> TARGET_PAGE_BITS] != 0xff)
> + ++phys_ram_dirty_by_word[(addr >> TARGET_PAGE_BITS) /
> + TARGET_LONG_BITS];
> +
> phys_ram_dirty[addr >> TARGET_PAGE_BITS] = 0xff;
> }
>
Why do you need a counter? It may be sufficient to set a single bit.
This reduces the memory overhead and perhaps cache thrashing.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-02-11 12:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-08 10:22 [Qemu-devel] [PATCH 1/3] qemu-kvm: Wrap phys_ram_dirty with additional inline functions OHMURA Kei
2010-02-11 12:42 ` Avi Kivity [this message]
2010-02-12 2:08 ` [Qemu-devel] " OHMURA Kei
2010-02-13 7:33 ` Avi Kivity
2010-02-15 5:05 ` Yoshiaki Tamura
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=4B73FB39.1000200@redhat.com \
--to=avi@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=ohmura.kei@lab.ntt.co.jp \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).