I thought this was a very good question (it stopped my brain from working for some time....anyway....it usually isn't working....and esp on post-April fool's day) - how to know if the kernel is SMP-enabled. And I misunderstood it for another question "how to know if I have a SMP system". The former is a configuration question (indep of hardware), and so checks on configuration is the solution. But the latter is a hardware problem....no matter how u configured the OS....SMP-hardware is indep of that....so how to know if the hardware is smp-enabled or not(not the kernel)? I don't know the answer for the 2nd one.....so I think Daniel Bonekeeper's answer is the only one that can answer that question. Alternatively, if u look hard enough into Intel manual (specifically the 3a and 3b manual) *I THINK* u may find an alternative answer there.....not sure for me now. but i vaguely remember Intel has a separate thin document on SMP hardware....possibly some MSR registers???? For within a single CPU detecting the number of cores is via CPUID command. (http://www.koders.com/cpp/fid3BC912972A64FC64C38645FD079927D1081454F9.aspx, MaxCore...() function) and the current linux kernel hardcoded the CPU number as well: for example, /proc/cpuinfo===> uses for_each_possible_cpu() to do enumeration: #define for_each_possible_cpu(cpu) for_each_cpu_mask((cpu), cpu_possible_map) and this depends on: #if NR_CPUS > 1 #define for_each_cpu_mask(cpu, mask) \ for ((cpu) = first_cpu(mask); \ (cpu) < NR_CPUS; \ (cpu) = next_cpu((cpu), (mask))) #else /* NR_CPUS == 1 */ where NR_CPUS is defined via Kconfig file (in arch/x86/Kconfig) - fixed at compilation as 8. So a more intelligent compiler (via some script, done at "make oldconfig" time) could possible generate a number for NR_CPUS that specifically tied to the actual number of CPUs that exists in the system. But do notice that there is a static variable in arch/x86/kernel/smpboot_32.c: cpucount that is initialized by do_boot_cpu() (which in turned is called by smp_boot_cpu(), which will loop the max NR_CPUS times to call do_boot_cpu()). So cpucount reflect the actual number of cpu in the system. cpucount info is also provided by the cpu mask map info, setup by start_secondary() (for each CPU) - which is called by do_boot_cpu(). everywhere u see for_each_cpu() macro, it is depending on the mask map to iterate. so the possible answer (me not sure) is to use the cpu mask map for cpu counting....otherwise put your function inside smpboot_32.c to read the static variable - cpucount. alternatively, redo what start_secondary() does - setting up an IPI to do cpu counting.... any bugs in my analysis???? thanks :-). On Wed, Apr 2, 2008 at 9:37 AM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote: > On Wed, Apr 2, 2008 at 12:27 AM, Scott Lovenberg > <scott.lovenberg@xxxxxxxxx> wrote: > > Robert P. J. Day wrote: > > > > > > > a simple one this time -- how can i tell if my currently-running > > > kernel is SMP capable? > > ehmmmm: > (as root) > # dd if=/dev/kmem skip=3G bs=1 | strings -a -t x | grep -i SMP > > 67210 2.6.22-14-generic (buildd@terranova) #1 SMP Tue Dec 18 08:02:57 UTC 2007 > 913a0 2.6.22-14-generic (buildd@terranova) #1 SMP Tue Dec 18 08:02:57 UTC 2007 > f73a4 BCPSMP > 2fc000 Linux version 2.6.22-14-generic (buildd@terranova) (gcc > version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #1 SMP > Tue Dec 18 08:02:57 UTC 2007 (Ubuntu 2.6.22-14.47-generic) > 2fcca8 alternatives_smp_module_del > 2fccc4 alternatives_smp_module_add > 2fd3d8 native_smp_call_function_mask > 2fd3f6 native_smp_send_reschedule > 2fd427 smp_call_function_single > 2fde40 2.6.22-14-generic SMP mod_unload 586 > 36eaa5 Use CONFIG_X86_GENERICARCH or CONFIG_X86_BIGSMP. > 36ecc8 <6>SMP alternatives: switching to SMP code > 36ecf4 <6>SMP alternatives: switching to UP code > ......... > > we saw SMP specific functions compiled in here...at least their symbols. > > regards, > > Mulyadi. > > > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
