From: Paolo Bonzini <pbonzini@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Jan Kiszka <jan.kiszka@web.de>, Chen Yufei <cyfdecyf@gmail.com>,
wang Tiger <tigerwang1986@gmail.com>,
Alexander Graf <agraf@suse.de>,
qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: Release of COREMU, a scalable and portable full-system emulator
Date: Sun, 25 Jul 2010 17:56:16 +0200 [thread overview]
Message-ID: <4C4C5EA0.6080408@redhat.com> (raw)
In-Reply-To: <AANLkTim0neWyCDcRFcsNjZ34AmbeDdGPymmKDqw-xOMo@mail.gmail.com>
On 07/23/2010 01:02 PM, Stefan Hajnoczi wrote:
>> In fact, we solve this problem through a really simple method.
>> In our prototype, we removed this piece of code like this:
>> void *qemu_get_ram_ptr(ram_addr_t addr)
>> {
>> ......
>>
>> /* Move this entry to to start of the list. */
>> #ifndef CONFIG_COREMU
>> /* Different core can access this function at the same time.
>> * For coremu, disable this optimization to avoid data race.
>> * XXX or use spin lock here if performance impact is big. */
>> if (prev) {
>> prev->next = block->next;
>> block->next = *prevp;
>> *prevp = block;
>> }
>> #endif
>> return block->host + (addr - block->offset);
>> }
>>
>> CONFIG_COREMU is defined when TCG parallel mode is configured.
>> And the list is more likely to be read only without hotplug device, so
>> we don't use a lock to protect it.
>> Reimplement this list with a lock free list is also reasonable, but
>> seems unnecessary. :-)
>
> Ah, good :).
For this one in particular, you could just use circular lists (without a
"head" node, unlike the Linux kernel's list data type, as there's always
a RAM entry) and start iteration at "prev".
Paolo
next prev parent reply other threads:[~2010-07-25 15:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-17 10:27 [Qemu-devel] Release of COREMU, a scalable and portable full-system emulator Chen Yufei
2010-07-20 21:43 ` Blue Swirl
2010-07-21 7:03 ` Chen Yufei
2010-07-21 17:04 ` Stefan Weil
2010-07-22 8:48 ` Chen Yufei
2010-07-22 11:05 ` [Qemu-devel] " Jan Kiszka
2010-07-22 12:18 ` [Qemu-devel] " Stefan Hajnoczi
2010-07-22 13:00 ` [Qemu-devel] " Jan Kiszka
2010-07-22 13:21 ` Stefan Hajnoczi
2010-07-22 15:19 ` wang Tiger
2010-07-22 15:47 ` Stefan Hajnoczi
2010-07-23 3:29 ` wang Tiger
2010-07-23 7:53 ` Jan Kiszka
2010-07-23 8:38 ` Alexander Graf
2010-07-23 9:13 ` Stefan Hajnoczi
2010-07-23 9:47 ` Jan Kiszka
2010-07-23 10:59 ` wang Tiger
2010-07-23 11:02 ` Stefan Hajnoczi
2010-07-25 15:56 ` Paolo Bonzini [this message]
2010-07-23 10:35 ` wang Tiger
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=4C4C5EA0.6080408@redhat.com \
--to=pbonzini@redhat.com \
--cc=agraf@suse.de \
--cc=cyfdecyf@gmail.com \
--cc=jan.kiszka@web.de \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=tigerwang1986@gmail.com \
/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.