1 |
Am 09.04.2013 05:50, schrieb Nilesh Govindrajan: |
2 |
> I have two Gentoo VMs at Hetzner and the CPU supports 64 bit (grep lm |
3 |
> /proc/cpuinfo = true). |
4 |
> |
5 |
> But something funny, gcc -march=native -mtune=native -v -E - 2>&1 |
6 |
> </dev/null returns this: |
7 |
> |
8 |
> Using built-in specs. |
9 |
> COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/gcc |
10 |
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper |
11 |
> Target: x86_64-pc-linux-gnu |
12 |
> Configured with: |
13 |
> /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure |
14 |
> --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3 |
15 |
> --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include |
16 |
> --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3 |
17 |
> --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man |
18 |
> --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info |
19 |
> --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4 |
20 |
> --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec |
21 |
> --disable-fixed-point --without-ppl --without-cloog --enable-lto |
22 |
> --enable-nls --without-included-gettext --with-system-zlib |
23 |
> --enable-obsolete --disable-werror --enable-secureplt --enable-multilib |
24 |
> --enable-libmudflap --disable-libssp --enable-libgomp |
25 |
> --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python |
26 |
> --enable-checking=release --disable-libgcj --enable-libstdcxx-time |
27 |
> --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix |
28 |
> --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all |
29 |
> --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3 |
30 |
> p1.11, pie-0.5.2' |
31 |
> Thread model: posix |
32 |
> gcc version 4.6.3 (Gentoo 4.6.3 p1.11, pie-0.5.2) |
33 |
> COLLECT_GCC_OPTIONS='-march=native' '-mtune=native' '-v' '-E' |
34 |
> /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -E -quiet -v - |
35 |
> -march=pentium-m -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt |
36 |
> -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mbmi -mno-tbm -mno-avx |
37 |
> -mno-sse4.2 -mno-sse4.1 --param l1-cache-size=32 --param |
38 |
> l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=generic |
39 |
> ignoring nonexistent directory "/usr/local/include" |
40 |
> ignoring nonexistent directory |
41 |
> "/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/include" |
42 |
> |
43 |
> #include "..." search starts here: |
44 |
> #include <...> search starts here: |
45 |
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include |
46 |
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include-fixed |
47 |
> /usr/include |
48 |
> End of search list. |
49 |
> # 1 "<stdin>" |
50 |
> <stdin>:1:0: error: CPU you selected does not support x86-64 instruction |
51 |
> set |
52 |
> |
53 |
> It is returning pentium-m as architecture, which indeed is 32bit. I'm |
54 |
> presently running the VM with -march=core2, but this is very weird. |
55 |
> |
56 |
> This is the /proc/cpuinfo: |
57 |
> |
58 |
> processor : 0 |
59 |
> vendor_id : GenuineIntel |
60 |
> cpu family : 6 |
61 |
> model : 2 |
62 |
> model name : QEMU Virtual CPU version 1.0 |
63 |
> stepping : 3 |
64 |
> microcode : 0x1 |
65 |
> cpu MHz : 3399.998 |
66 |
> cache size : 4096 KB |
67 |
> fpu : yes |
68 |
> fpu_exception : yes |
69 |
> cpuid level : 4 |
70 |
> wp : yes |
71 |
> flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca |
72 |
> cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl pni vmx |
73 |
> cx16 popcnt hypervisor lahf_lm |
74 |
> bogomips : 6799.99 |
75 |
> clflush size : 64 |
76 |
> cache_alignment : 64 |
77 |
> address sizes : 40 bits physical, 48 bits virtual |
78 |
> power management: |
79 |
> |
80 |
> Any idea what should be the march/mtune value? |
81 |
> |
82 |
|
83 |
I don't have any experience with Hetzner's VMs - I only use their |
84 |
dedicated machines :) |
85 |
|
86 |
But as a more generic tip, you should install gentoo in VMs only with |
87 |
generic optimization. You can not safely rely on what CPU your VM will |
88 |
get. Maybe in 6 months the host your vm is on crashes, and your vm will |
89 |
be migrated to a new system with totally different cpu (actual hardware |
90 |
cpu or the cpu configuration that qemu is going to emulate). |