numa: introduce --numa-distance #206
Conversation
arighi
force-pushed
the
numa-distance
branch
2 times, most recently
from
476512f to
72f71d4
Compare
Introduce a new option `--numa-distance SRC,DST=VAL` to define the
distance cost between two NUMA nodes and simulate non-uniform memory
access.
Example usage:
$ vng -r --cpu 8 -m 4G \
> --numa 1G,cpus=0-1 --numa 1G,cpus=2-3 \
> --numa 1G,cpus=4-5 --numa 1G,cpus=6-7 \
> --numa-distance 0,1=51 --numa-distance 0,2=31 --numa-distance 0,3=41 \
> --numa-distance 1,2=21 --numa-distance 1,3=61 \
> --numa-distance 2,3=11 -- numactl -H
available: 4 nodes (0-3)
node 0 cpus: 0 1
node 0 size: 1006 MB
node 0 free: 974 MB
node 1 cpus: 2 3
node 1 size: 953 MB
node 1 free: 919 MB
node 2 cpus: 4 5
node 2 size: 943 MB
node 2 free: 894 MB
node 3 cpus: 6 7
node 3 size: 1006 MB
node 3 free: 965 MB
node distances:
node 0 1 2 3
0: 10 51 31 41
1: 51 10 21 61
2: 31 21 10 11
3: 41 61 11 10
Signed-off-by: Andrea Righi <[email protected]>
arighi
force-pushed
the
numa-distance
branch
from
72f71d4 to
865e158
Compare
| err_msg = f"error: invalid distance '{arg}', " + \ | ||
| "NUMA distance string must be in the format SRC,DST=VAL" | ||
| arg_fail(err_msg, show_usage=False) | ||
| self.virtme_param["numa_distance"] = numa_dist_str |
There was a problem hiding this comment.
Out of curiosity, why not doing the parsing and moving this "complexity" to virtme-run?
There was a problem hiding this comment.
Out of curiosity, why not doing the parsing and moving this "complexity" to
virtme-run?
At some point in the future I'd be nice to just drop virtme-run and have only vng. The virtme-run interface is maintained only for backward compatibility with the old virtme tool and vng is like a front-end to the old interface. But ultimately it'd be nice to drop the old interface and just have a front-end to qemu. That's the reason why I usually prefer to add complexity and new abstractions to vng directly.
There was a problem hiding this comment.
Out of curiosity, why not doing the parsing and moving this "complexity" to
virtme-run?At some point in the future I'd be nice to just drop virtme-run and have only vng. The virtme-run interface is maintained only for backward compatibility with the old virtme tool and vng is like a front-end to the old interface. But ultimately it'd be nice to drop the old interface and just have a front-end to qemu. That's the reason why I usually prefer to add complexity and new abstractions to vng directly.
Thank you, I see! And that's not what I did in my previous PR :)
Please note that I'm still using virtme-run directly in my automated scripts, mainly because it works, and I don't need vng to build the kernel (I already had that, and when I switched, vng could not build the kernel in a different build dir :) ).
There was a problem hiding this comment.
It's ok, a lot of people are still using virtme-run. At some point we could also decide to do a big refactoring, merge everything into a single tool and provide backward compatible aliases. In fact, there's no reason to have a python script that calls another python script, it's just unnecessary overhead, but it's not terrible and we can live with that for now.
| def _get_virtme_numa_distance(self, args): | ||
| if args.numa_distance is not None: | ||
| if not args.numa: | ||
| arg_fail("error: --numa-distance can be used only with --numa", show_usage=False) |
There was a problem hiding this comment.
Because the issue is due to a wrong using, maybe show_usable=False is not needed?
But up to you, it is also easy to run vng -h :)
(Same below for the parsing issue).
There was a problem hiding this comment.
Yeah, initially I was showing the help, but I thought it was a bit too verbose and it could hide the actual error, so I added show_usage=False. :)
Introduce a new option
--numa-distance SRC,DST=VALto define the distance cost between two NUMA nodes and simulate non-uniform memory access.Example usage: