1 |
On 14/08/2013 13:15, Bruce Hill wrote: |
2 |
> On Wed, Aug 14, 2013 at 12:18:41PM +0700, Pandu Poluan wrote: |
3 |
>> Hello list! |
4 |
>> |
5 |
>> My company has 2 HP DL585 G5 servers and 5 Dell R... something servers. All |
6 |
>> using AMD processors. They currently are acting as XenServer hosts. |
7 |
>> |
8 |
>> How do I determine the 'least common denominator' for Gentoo VMs (running |
9 |
>> as XenServer guests), especially for gcc flags? |
10 |
>> |
11 |
>> I know that the (theoretical) best performance is to use -march=native , |
12 |
>> but since the processors of the HP servers are not exactly the same as the |
13 |
>> Dell's, I'm concerned that compiling with -march=native will render the VMs |
14 |
>> unable to migrate between the different hosts. |
15 |
|
16 |
A couple of points: |
17 |
|
18 |
* The effect of setting -march=native depends on the characteristics of |
19 |
the CPU (be it virtual or otherwise) |
20 |
* The characteristics of the vCPU are defined by qemu's -cpu parameter |
21 |
* qemu can emulate features not implemented by the host CPU (at a cost) |
22 |
|
23 |
One way to go about it is to start qemu with a -cpu model that exposes |
24 |
features that all of your host CPUs have in common (or a subset |
25 |
thereof). In that case, -march=native is fine because all of the |
26 |
features that it detects as being available will be supported in |
27 |
hardware on the host side. |
28 |
|
29 |
Another way is to expose the host CPU fully with "-cpu host" and to |
30 |
define your guest CFLAGS according to the most optimal subset. If you |
31 |
are looking for a 'perfect' configuration then this this would be the |
32 |
most effective method, if applied correctly. |
33 |
|
34 |
Irrespective of the method, by examining /proc/cpuinfo and using the |
35 |
diff technique mentioned by Bruce, you should be able to determine the |
36 |
optimal configuration. |
37 |
|
38 |
Finally, in cases where the host CPUs differ significantly - in that |
39 |
native would imply a different -march value - you may choose to augment |
40 |
your CFLAGS with -mtune=generic to even out performance across the |
41 |
board. I don't think this would apply to you though. |
42 |
|
43 |
>> |
44 |
>> Note: Yes I know the HP servers are much older than the Dell ones, but if I |
45 |
>> go -march=native then perform an emerge when the guest is on the Dell host, |
46 |
>> the guest VM might not be able to migrate to the older HPs. |
47 |
> |
48 |
> To check what options CFLAGS set as -march=native would use: |
49 |
> gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p' |
50 |
> (the first thing in the output is what CPU -march=native would enable) |
51 |
> |
52 |
> Then you can run: |
53 |
> diff -u <(gcc -Q --help=target) <(gcc -march=native -Q --help=target) |
54 |
> to display target-specific options, versus native ones. |
55 |
> Assuming the 2 HP servers are identical, and the 5 Dell servers are identical, |
56 |
> you then only need to get the commonality of two processors (HP and Dell). |
57 |
> Since they're both AMD, you should have a good set of common features to help |
58 |
> you determine that "least common denominator", or target. |
59 |
> |