add 18th iteration of classifier

1 files changed, 43 insertions, 0 deletions

diff --git a/results/classifier/118/performance/2848 b/results/classifier/118/performance/2848
new file mode 100644
index 000000000..c6ff1a455
--- /dev/null
+++ b/results/classifier/118/performance/2848
@@ -0,0 +1,43 @@
+i386: 0.981
+performance: 0.965
+x86: 0.955
+VMM: 0.894
+graphic: 0.758
+device: 0.691
+architecture: 0.665
+semantic: 0.657
+vnc: 0.558
+kernel: 0.484
+socket: 0.461
+ppc: 0.438
+risc-v: 0.330
+virtual: 0.326
+PID: 0.317
+network: 0.305
+boot: 0.303
+mistranslation: 0.286
+arm: 0.255
+KVM: 0.214
+register: 0.177
+TCG: 0.177
+hypervisor: 0.169
+files: 0.168
+permissions: 0.166
+debug: 0.132
+user-level: 0.119
+assembly: 0.093
+peripherals: 0.065
+
+i386 max_cpus off by one
+Description of problem:
+X86 VMs are currently limited to 255 vCPUs (`mc->max_cpus = 255;` in `pc.c`).
+The first occurrence i can find of this limit is in d3e9db933f416c9f1c04df4834d36e2315952e42 from 2005 where both `MAX_APICS` and `MAX_CPUS` was set to 255. This is becoming relevant for some people as servers with 256 cores become more available. 
+
+**Can we increase the limit to 256 vCPUs?** 
+I think so. 
+
+Today, the APIC id limit (see `apic_id_limit` in `x86-common.c`) is based on the CPU id limit. 
+According to the a comment for `typdef uint32_t apic_id_t;` (see `topology.h`), we can have 256 APICs, but more APICs require x2APIC support. 
+APIC seems to be no hindrance to increase max_cpus to 256. 
+
+**Can we increase the limit to 512?** Maybe not? We need x2APIC support of which i have no clue. Also there is always a performance risk of exceeding the size at which current data structures work efficiently.