enable more virtual cores for x86#17
Conversation
The unit tests enabled via CONFIG_KCSAN_TEST require >1 CPU to run. Enable more cpu's via QEMU's `-smp <n>` command line flag. Not sure if we should just do this for all ARCHs and if we should use a value like 8 or min(nproc, 8). Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
|
or maybe we should only do this for interactive mode? Though most systems these days have more than one core, so I would prefer to test that. |
|
also, I think |
|
We could start with If we encounter issues, we could do something like |
|
Also, do we want to do this for all machines? Or just x86? |
yeah might as well, let me send a fix |
|
Looks like for 32b x86, we'll get:
|
|
CONFIG_BIGSMP=y should allow 32 or 64 CPUs |
Done, please re-review. |
|
When trying multi_v5_defconfig. Seems we have to do just 2 to avoid changing a bunch of configs. |
ARMv5 has no SMP support at all, it only works in ARMv6K or higher. |
nickdesaulniers
force-pushed
the
smp_nproc
branch
from
5789a71 to
0cade4a
Compare
|
ok, dropped the latest patch (kept them separate since we can squash+merge in github UI). I only really care about this for x86_64 ATM. If that changes, or we feel strongly about it, we can change it. Otherwise YAGNI. |
As noted on the review for ClangBuiltLinux#17, when booting an i386_defconfig kernel, there is a lot of spam in the boot logs because CONFIG_NR_CPUS is set to 8: [ 0.020644] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor 8/0x8 ignored. [ 0.021302] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor 9/0x9 ignored. [ 0.021964] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor 10/0xa ignored. [ 0.022642] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor 11/0xb ignored. With large machines, this can be quite noisy. Refactor the logic for finding a sensible value based on CONFIG_NR_CPUS if a config can be found or defaulting to 8 if not. Signed-off-by: Nathan Chancellor <nathan@kernel.org>
As noted on the review for ClangBuiltLinux#17, when booting an i386_defconfig kernel, there is a lot of spam in the boot logs because CONFIG_NR_CPUS is set to 8: [ 0.020644] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor 8/0x8 ignored. [ 0.021302] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor 9/0x9 ignored. [ 0.021964] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor 10/0xa ignored. [ 0.022642] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor 11/0xb ignored. With large machines, this can be quite noisy, as there is one print out for every CPU above 8. Refactor the logic for finding a sensible value based on CONFIG_NR_CPUS if a config can be found. If no config is available, default to 8, which is the default value for i386_defconfig. Signed-off-by: Nathan Chancellor <nathan@kernel.org>
As noted on the review for ClangBuiltLinux#17, when booting an i386_defconfig kernel, there is a lot of spam in the boot logs because CONFIG_NR_CPUS is set to 8: [ 0.020644] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor 8/0x8 ignored. [ 0.021302] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor 9/0x9 ignored. [ 0.021964] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor 10/0xa ignored. [ 0.022642] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor 11/0xb ignored. With large machines, this can be quite noisy, as there is one print out for every CPU above 8. Refactor the logic for finding a sensible value based on CONFIG_NR_CPUS if a config can be found. If no config is available, default to 8, which is the default value for i386_defconfig. Signed-off-by: Nathan Chancellor <nathan@kernel.org>
4 participants
The unit tests enabled via CONFIG_KCSAN_TEST require >1 CPU to run.
Enable more cpu's via QEMU's
-smp <n>command line flag.Not sure if we should just do this for all ARCHs and if we should use a
value like 8 or min(nproc, 8).
Signed-off-by: Nick Desaulniers ndesaulniers@google.com