Re: [PATCH] KVM: Remove arch specific components from the general code

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Rusty Russell wrote:
> On Thu, 2007-07-26 at 14:05 +0300, Avi Kivity wrote:
>   
>> Rusty Russell wrote:
>>     
>>> 	Great minds think alike.  This is a little rough, but I decided to send
>>> it out tonight because it would make your life easier...
>>>       
>> What about my life?  Which patch should I apply first?
>>     
>
> Such are the responsibilities of command, Avi.
>
> (Actually, the normal way is to send us both away to create a combined
> patch set, and thus make it Not Your Problem).
>
>   

That tactics is used when one wants to get rid of both pesky submitters,
allowing one a much-earned rest.

Alas, I want those patches.

>>> ===
>>> Dynamically allocate vcpus
>>>
>>> This patch converts the vcpus array in "struct kvm" to a linked list
>>> of VCPUs, and changes the "vcpu_create" and "vcpu_setup" hooks into
>>> one "vcpu_create" call which does the allocation and initialization of
>>> the vcpu (calling back into the kvm_vcpu_init core helper).
>>>       
>> Linked list?  So that the in-kernel apic code has to traverse a list, 
>> making sure the cpu still knows how to transfer dirty cache lines for 
>> every vcpu?
>>
>> A good old fashioned pointer array will suit just fine.
>>     
>
> So the in-kernel apic code has to traverse every element in the array?
> That is clearly better because?  

Rusty, don't make me do this.

Arrays give you random access.  Hand the array an index, and it hands
you back the vcpu, no questions asked.  Not so with lists.  Think guest
issuing an smp_call_function_{single,mask}.

> We get to place an artificial maximum
> and keep a ceiling variable like the existing code does?
>
>   

The real maximum comes from the single-threaded kvm mmu.  But with a
pointer array, the cost of raising that maximum becomes quite low (8
bytes/potential vcpu).  Even if you raise it to 256, it's still quite low.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/