[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: how to tell if my kernel is SMP enabled?
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