I have a Core 2 duo.

Whenever I monitor my CPU's, it seems only the first is ever utilized, with the second always being at 0%.

Does this mean it is not being used, or just not being reported as in use?

Is there anything I could do to improve the situation if it is not being used as much as it could be?


On Windows, I can assign processes to both cores, or either one. Is there a way to do something similar in Linux?

The scheduler should handle things for you - unless you just have one big task. Try this twice from a terminal, and check your monitor (use "kill %1" and "kill %2" to get rid of them)

Have you got a SMP kernel loaded? Run the command 'uname -a' ( without the quotes ) and look for the SMP in the name. If it is not SMP, you probably are not using both cores.

Here is what I see on my system -

Yep, it's an SMP kernel.

I tried the loop command twice, and using powertop it shows only the first cpu running at 100%, the second still at 0.

How are you monitoring your CPUs. A single threaded process can only run on one cpu at a time (*) so it's quite possible that you could have one running at 100% and the other doing 0-5% but if your second cpu never shows any activity then that's certainly a little strange. Try running 2 loop commands at once.

The 'taskset' command will allow you to assign cpu affinity, but I suspect that unless you have a really good reason to use it, you're only likely to make your system run slower. The CPU Scheduler probably understands you system's workload far better than you do.


(*) That was part of the reason I decided to go for a dual 2.8Ghz box rather than a slower 2.4 quad box (plus the dual was much cheaper). The quad has more processing muscle in total, but a single task will complete faster on my faster clocked dual core.

I am just monitoring with the powertop program. I ran two loop commands, and the second cpu never shows any activity.

The only reason I ever used to set a processes affinity was to put firefox on it's own core if it started being to beastly, which resulted in a marked improvement.

try running the normal top program and press the "1" key to show individual cpus.

If firefox starts to hog cpu, then a better option would be to alter it's nice value to protect the other processes, setting a cpu-affinity in that sort of situation is not really what cpu-affinity is designed for, but it's your system and your choice.

If there are two "processor" entries in /proc/cpuinfo, you should be using them both.
Simple as that.

Hmm, top shows them both in use, although neither one as being above 20% utilization even though it shows the loop command taking 99% of my cpu.

Obviously they areboth being used, I just thought it was odd it wasn't reported as such(or so I thought)

I just wanted to ask you about cpu affinity? You say it was not designed to be used the way I used it...what was it designed for? Why is it a bad idea to use it as I do, when I see a improvement by doing so?

Just curious, and would like to learn more.

By setting cpu affinity what you're doing is restricting the choices the cpu scheduler can make about where to run a program. This could potentially make overall performance worse rather than better depending on the situation.

System affinity was really designed for very specific situations where you want a task to stay on a single cpu to maximise cache hits and register usage. As soon as you introduce a multi-tasking/time-slicing system such as unix where the task on the cpu is regularly being swapped any advantages from cache hits and register use that setting cpu-affinity would bring are going to be lost anyway. Unless you tell everything else not to run on that cpu, setting the affinity really won't buy you that much in this sort of environment and will more likely hinder the scheduler in doing its job. A lot of thought tends to go into Scheduler algorithms, best to leave it to it.

Now if your problem is that firefox is too greedy at times and overall system responsiveness is suffering then tell the scheduler to give less priority to firefox with nice/renice. This will help the responsiveness/performance of other processes without artificially limiting where the scheduler can run things and overall performance should be better.

1 members found this post helpful.

Thanks for explaining that