On 06/28/2010 07:20 PM, Anthony Liguori wrote:
To avoid this I'd like to see the pinning done from within QEMU. I
am not sure whether calling numactl via system() and friends is
OK, I'd prefer to run the syscalls directly (like in patch 3/3)
and pull the necessary options into the -numa pin,... command
line. We could mimic numactl's syntax here.
Definitely not use system(), but IIRC numactl has a library interface?
Right, that is what I include in patch 3/3 and use. I got the
impression Anthony wanted to avoid reimplementing parts of numactl,
especially enabling the full flexibility of the command line
interface (like specifying nodes, policies and interleaving).
I want QEMU to use the library and pull the necessary options into
the -numa pin,... parsing, even if this means duplicating numactl
functionality.
I agree with that. It's a lot easier to use a single tool than to
try to integrate things yourself, the unix tradition of grep | sort |
uniq -c | sort -n notwithstanding. Especially when one of the tools
is qemu.
I could disagree more here. This is why we don't support CPU pinning
and instead provide PID information for each VCPU thread.
Good point. That also allows setting priority, etc.
The folks that want to use pinning are not notice users. They are not
going to be happy unless you can make full use of existing tools.
That means replicating all of numactl's functionality (which is not
what the current patches do) or enable numactl to be used with a guest.
Yeah. Unfortunately, that also forces us to use non-anonymous memory.
So it isn't just where to put the functionality, it also has side effects.
--
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
