|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [RFC] Memory API |
Date: | Wed, 18 May 2011 20:05:23 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10 |
On 05/18/2011 07:42 PM, Jan Kiszka wrote:
> > You cannot do this properly with a single dispatch table because the > behavior depends on where in the hierarchy the I/O is being handled. Ah, now I remember why I did not follow that path: Not invasiveness, but performance concerns. I assume TLB refills have their share in TCG performance, and adding another lookup layer, probably for every target, will be measurable. I was wondering if that is worth the, granted, cleaner design.
We can have a per-cpu hash table and flattened slots list, though that seems wasteful. I agree that a tree walk is too expensive for a tlb miss.
We'll start however with the existing phys_desc, so no performance concerns, and no per-cpu APIC address either (btw it is broken in kvm as well, and hard to fix - we don't want per-cpu page tables).
-- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |