Andi Kleen wrote:
I don't think the first one works without the second. Calling getcpu()
on startup is meaningless since the initial placement doesn't take the
Who said anything about startup? The idea behind getcpu() is to call
it every time you allocate someting.
Qemu only allocates on startup (though of course the kernel actually
allocates the memory lazily).
Please explain. When would you call getcpu() and what would you do at
that time?
This could happen completely in the kernel (not an easy task), or by
There were experimental patches for tieing memory migration to cpu migration
some time ago from Lee S.
having a second-level scheduler in userspace polling for cpu usage an
rebalancing processes across numa nodes. Given that with virtualization
you have a few long lived processes, this does not seem too difficult.
I think I would prefer to fix that in the kernel. user space will never
have the full picture.
On the other hand, getting everyone happy so this can get into the
kernel will be very difficult. Many workloads will lose from this;
we're trying to balance both memory affinity and cpu balancing, and each
workload has a different tradeoff.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
