On which core is Linux kernel running on Dual-core machine?
 

I am new to Dual-core world and I just got a AMD X2 64-bit Dual Core processor machine and have installed Debian Lenny (64-bit) on it with the SMP kernel (64-bit).

Now as I understand dual-core means there are two cores i.e. the OS see two cpus as correctly identified by:
Now my following question might sound little strange but I got curious:
Is there a way to know on which of the two cores is the Linux kernel running on? Does it run partially on both the cores or does it just runs on a single core? If it runs on a single core, then which core?

How can I determine this?

As I understand it, the kernels run on both cores. I know that's how it works for multiprocessor machines, but I'm not sure about multicore.

Linux boots on the number one core, then shifts to multiprocessor mode at some point when it is ready. I believe that the number one core continues to allocate processes to all cores, but I could be wrong on that point.

Wonder if there is tool/utility to find that out just like there are so many for determining whether the kernel is a dual-core or not (proc/cpuinfo and top).

Edit: I just noticed that this is my 1000th post.....

The kernel would run on both cores (or as many cores as is available).
The kernel would also allocate threads from each application to an appropriate core.

I don't know which core would do the scheduling to allocate threads to a particular core. It may not even be a static thing.

To complicate things even further, there is a degree of hardware scheduling between the cores.

--Ian

Do you have evidence to support this statement, or merely presuming a "SMP kernel" might (should ?) work this way ???.

I'm inclined to agree with Quakeboy02, but I haven't tracked through the code. Depends on what one means by "the kernel" of course - (some) kernel threads can run on any "engine". But then again, they can be bound to a specific "engine".
The (non-threaded) kernel itself ??? - mmmm. I'd be thinking just the one - Linux generally works that way to ensure things like cache flushes are minimized. Maybe one should peruse the code on a balmy New Years Eve rather than drinking and enjoying oneself.
.
.
Maybe.

Isn't the "system" time reported by top the answer to this question?

Run top. Press "1" if necessary to see the categories of time per core. Watch it while you run some ordinary tasks.

all discussion on SMP and the Linux kernel I find are centered around the scheduler and threads or processes..
just tagging this thread so I can see what you all may find..

http://www.ibm.com/developerworks/library/l-linux-smp/
http://www.ibm.com/developerworks/li...-linux-kernel/
http://www.ibm.com/developerworks/li...y/l-scheduler/



Interesting topic.

If you like "geek" toys, install gkrelm (although, come to think of it, it's not the the Ubuntu repositories). It runs on most window managers (but "best" under GNOME) and, among other things, can show you a "5-second updated" chart of CPU usage by core.

<edit>
Oops! :eek: apt-get install gkrellm does get it.
</edit>

gkrellm is a cool tool. Looks cool on the cpu usuage of a quad core and compiling a new kernel with the -j8 option with make. It is working all 4 processors when compiling.

Brian

If you have a non-smp kernel (which would be old, presumably), my experience is that it runs on Core 0 and Core 1 idles.

SMP kernels (anything recent should be SMP, except for oddball things that are specifically low-resource) split the load over the two (err, sometimes with a load of zero for one cores, if the load is low).

Note that ksysguard and Gnome system monitor can also do the trick of showing the load for the individual cores.

very interesting indeed, I asked that question to myself some time ago and I've learned some interesting stuff reading this...

Good work!

I think the process splitting is done by the pipelining system of the cores means, that software does not have any possibility to choose where to be executed.
So I think if the pipeline recognizes a call instruction then it gives that code until ret (iret) to the next free PU. So you can say that an interrupt (IRQ) is executed surely only on one PU. I can also imagine that a arithmetic work on the pipeline is pushed forward to a free PU and when the result is calculated then the other PU is at that point it needs that result.
Before I guess something wrong, you can download the datasheets for the AMD multicore CPU chips from here:
http://www.amd.com/us-en/Processors/..._15343,00.html

Here's an interesting article on interrupt scheduling in an SMP environment.

http://software.intel.com/en-us/arti...essor-affinity

If this were true, you wouldn't be able to set affinity. And if the pipelining system were doing this, which part ensures that instructions work on the correct registers?