Glauber Costa wrote:
I think the main point here is that currently, one of the showstopers
for scalability,
is the lack of fine grained locking. And we don't really know how the
code will look like
after that. It can very well change completely, rendering this work as
totally void.
I don't t
Jes Sorensen wrote:
Avi Kivity wrote:
Jes Sorensen wrote:
What I meant was that I was able to compile the code, and there was
only
one piece left that needed that function, which is why I moved it and
made it static in the acpi code.
That's because there is another static array in acpi.c...
On Wed, Nov 12, 2008 at 11:02 AM, Jes Sorensen <[EMAIL PROTECTED]> wrote:
> Avi Kivity wrote:
>>
>> Jes Sorensen wrote:
>>>
>>> What I meant was that I was able to compile the code, and there was only
>>> one piece left that needed that function, which is why I moved it and
>>> made it static in th
Avi Kivity wrote:
Jes Sorensen wrote:
What I meant was that I was able to compile the code, and there was only
one piece left that needed that function, which is why I moved it and
made it static in the acpi code.
That's because there is another static array in acpi.c...
Which array are you
Jes Sorensen wrote:
Avi Kivity wrote:
The code I mentioned only runs if the -no-kvm-irqchip option is
passed. It's not the highest performing option...
What I meant was that I was able to compile the code, and there was only
one piece left that needed that function, which is why I moved it an
Jes Sorensen wrote:
If we have reasons where we actually rely on the cpu number, and thats
not counting end-user pretty-number-print concerns, then I found that
we practically never use the cpu number. If we really use it a lot, I
agree we need a fast way, I just didn't hit it in my builds. What
Avi Kivity wrote:
Jes Sorensen wrote:
Sorry, but this is riciculous. Please try and take a look at where the
search is performed. It's *solely* in the ACPI hot plug code.
There are other places we want a cpu from a cpu_index. Like the apic
code (admittedly that's only using the userspace ap
Avi Kivity wrote:
The code I mentioned only runs if the -no-kvm-irqchip option is passed.
It's not the highest performing option...
What I meant was that I was able to compile the code, and there was only
one piece left that needed that function, which is why I moved it and
made it static in t
Anthony Liguori wrote:
Just do a linear search of the CPUState list and be done with it.
This smells of premature optimization greatly. I would be amazed if
walking the CPUState list is ever on the fast path or will ever be.
Really, if you need to go from cpu_index => CPUState, it suggests
Avi Kivity wrote:
My patch gets rid of the pointless MAX_CPUS sized array, which doesn't
buy us anything. In fact, most of the changes in my patch makes the
code simpler, because it removes a stack of silly cases where qemu uses
env->cpu_index to get into the array, just to hide CPUState from l
Jes Sorensen wrote:
Avi Kivity wrote:
Jes Sorensen wrote:
Move contents of struct vcpu_info directly into CPU_COMMON. Rename
struct qemu_kvm_work_item to qemu_work_item as it really isn't KVM
specific.
Well, it is actually kvm specific, since qemu doesn't have vccpu
threads.
Hi Avi,
Antho
Jes Sorensen wrote:
Sorry, but this is riciculous. Please try and take a look at where the
search is performed. It's *solely* in the ACPI hot plug code.
There are other places we want a cpu from a cpu_index. Like the apic
code (admittedly that's only using the userspace apic, which is
non-
Avi Kivity wrote:
Yes, but I believe the whole point of jes patches is to remove those
limits.
So we could linear search huge lists? Or code hashes where arrays would
do? No, sir.
An array of pointers statically sized at MAX_CPUS is fine. If you
insist, you can realloc() it on demand.
Avi Kivity wrote:
Jes Sorensen wrote:
Move contents of struct vcpu_info directly into CPU_COMMON. Rename
struct qemu_kvm_work_item to qemu_work_item as it really isn't KVM
specific.
Well, it is actually kvm specific, since qemu doesn't have vccpu threads.
Hi Avi,
Anthony suggested I moved t
Avi Kivity wrote:
Glauber Costa wrote:
By far it is not. But at least it does not depend on any kvm-specific
data, and works
for both qemu and kvm. So it's better to be this way.
If we change this scheme to a better one, like a hash table, then
it'll improve both qemu and kvm.
There are simp
Glauber Costa wrote:
Yes, but I believe the whole point of jes patches is to remove those
limits.
So we could linear search huge lists? Or code hashes where arrays would do?
No, sir.
An array of pointers statically sized at MAX_CPUS is fine. If you insist,
you can realloc() it on dem
On Tue, Nov 4, 2008 at 12:40 PM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Glauber Costa wrote:
>>>
>>> There are simpler data structures. An example is an array. Since we
>>> have
>>> an upper limit on the number of cpus (->max_cpus) there are no issues
>>> with
>>> scaling (unlike with the algori
Glauber Costa wrote:
There are simpler data structures. An example is an array. Since we have
an upper limit on the number of cpus (->max_cpus) there are no issues with
scaling (unlike with the algorithm above).
Yes, but I believe the whole point of jes patches is to remove those limits.
On Tue, Nov 4, 2008 at 12:30 PM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Glauber Costa wrote:
>>>
>>> This can't be the best way of determining the env pointer from a cpu
>>> number.
>>>
>>
>> By far it is not. But at least it does not depend on any kvm-specific
>> data, and works
>> for both qemu
Glauber Costa wrote:
This can't be the best way of determining the env pointer from a cpu number.
By far it is not. But at least it does not depend on any kvm-specific
data, and works
for both qemu and kvm. So it's better to be this way.
If we change this scheme to a better one, like a has
On Tue, Nov 4, 2008 at 9:54 AM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Jes Sorensen wrote:
>>
>> So here we go, trying to catch up on the PCI passthrough patch revision
>> number, here's v5 of the struct vcpu_info patch.
>>
>> In the end I decided to merge the contents of struct vcpu_info directly
Jes Sorensen wrote:
So here we go, trying to catch up on the PCI passthrough patch revision
number, here's v5 of the struct vcpu_info patch.
In the end I decided to merge the contents of struct vcpu_info directly
into CPU_COMMON as it was silly to create new files just to remove them
in the nex
Hi,
So here we go, trying to catch up on the PCI passthrough patch revision
number, here's v5 of the struct vcpu_info patch.
In the end I decided to merge the contents of struct vcpu_info directly
into CPU_COMMON as it was silly to create new files just to remove them
in the next patch again.
T
23 matches
Mail list logo
