How can I get Kubuntu to use all 4 cores?

[lcorken]

I have the CPU widget on my desktop and I have never seen all 4 cores used at once more that about a couple percent. If it is converting an audio file or renderring a video it will max out at most 2 cores. It does alternate between all 4 cores so I know it sees them.

I read some where that 2 faster cores is better than 4 slower one. Don't remember where I saw that.

I suspect this is normal operation but am curious about it. Is this a function of the APPs or the Kernel or some other system thing?

Phenom II X4,

Ken.

[GreyGeek]

Kubuntu is built using Ubuntu, which uses Debian. Debian runs a SMP-enabled kernel by default.

Basically, the more apps you run at the same time the more likely all of your cores and its threads will be used. For a given app to use all the cores it must be designed during coding to do so.

Many programs, like GIMP for example, have settings where you can set it to use as many cores as you want or have. But, for the most part, KDE and most apps will use multi-cores and are thread safe.

You may want to run memtest86 from the grub boot screen and verify that all of your RAM is working by having the test go through a complete 100% check.

The package sysstat contains mpstat, which can show CPU utilization:

mpstat -P ALL

My CPU is an i3 M370 with 2 cores and 2 threads. Using mpstat shows:

$ mpstat -P ALL
Linux 3.2.0-21-generic (jerry-Aspire-7739)      04/02/2012      _x86_64_        (4 CPU)


06:41:37 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
06:41:37 PM  all    8.19    0.08    1.52    0.59    0.00    0.09    0.00    0.00   89.53
06:41:37 PM    0    6.81    0.08    2.10    1.01    0.00    0.35    0.00    0.00   89.64
06:41:37 PM    1    4.87    0.09    1.05    1.09    0.00    0.01    0.00    0.00   92.89
06:41:37 PM    2   13.20    0.07    1.82    0.17    0.00    0.00    0.00    0.00   84.73
06:41:37 PM    3    7.86    0.05    1.13    0.09    0.00    0.00    0.00    0.00   90.87
:~$

mpstat -P ALL 5

will check the cores every five seconds.

PS- For got to mention that

cat /proc/cpuinfo

is where mpstat gets its info.

[jlittle]

... If it is converting an audio file or renderring a video ...

What applications are you using to perform these tasks? As GreyGeek says,

for a given app to use all the cores it must be designed during coding to do so

[lcorken]

Thanks guys. I think you answered my questions.
The Kernel is designed to use all available cores as the programs request.

"mpstat -P ALL" showes all cores working. I'll run mem test later.
I found the core setting in Gimp. That seems to work fine.

I use kdenlive to edit videos: interestinglly it seems to uses 4 cores when editing but only one when rendering? Need to play with that more to see what's really goning on.

K3b to convert mp3 to Wav(sox) seems to use only 1 core. Need to experement more with K3b and Audacity to see what's happening.

Not ready to change source and recompile this stuff yet. My geek hat is in the shop for repair.

Ken.

[GreyGeek]

The K3b author ran into a threading problem but neither Trolltech nor Nokia wanted to implement his particular solution. I never paid much attention to the controversy because K3b did all that I wanted it to do. I guess it is resolved now, at least for me. I burn CDs without a problem.

The problem with threading is the classic "bank account update" problem, where Joe and Sally add and subtract money from their joint account at the same time. The bank account has to be locked while each one does their thing so that the postings to the general ledger aren't using the wrong numbers.

Basically, Qt apps use the QThread and QMutex classes to set up more than one path of data manipulation at the same time. It is discussed in the documentation on QMutex, below.

http://qt-project.org/doc/qt-4.8/QThread.html

http://qt-project.org/doc/qt-4.8/qmutex.html#details

Each thread gets its own stack from the operating system. The operating system also determines the default size of the stack. You can use

setStackSize

() to set a custom stack size. Each QThread can have its own event loop. You can start the event loop by calling

exec

(); you can stop it by calling

exit

() or

quit

(). Having an event loop in a thread makes it possible to connect signals from other threads to slots in this thread, using a mechanism called

queued connections

. It also makes it possible to use classes that require the event loop, such as

QTimer

and

QTcpSocket

, in the thread. Note, however, that it is not possible to use any widget classes in the thread.

In Qt "Signals & Slots" are an elegant solution to the "call back" kludge problem. It was so good that the GTK AIP copied it into their object classes. (A benefit of the GPL - rising tides TRULY raise all boats!) The queued connections technique uses signals and slots. A signal is usually an event, like a mouse click or a button press, or some other interrupt handed to the event loop. A slot is a function which can accept the event when it is passed as a parameter.

Here is a line of code with a signal and a slot, which are connected to each other by the "connect" keyword, which is part of Qt's "QOBJECT" base class:

connect(ui.btnQUIT,           SIGNAL(clicked()),            this,    SLOT(QuitClicked()));

It connects the user interface Quit button to the QuitClick function which closes the user interface and shuts down the database connection (example borrowed from an app I wrote):

void homestead::QuitClicked() {
    // close the database connection
    QSqlDatabase db = QSqlDatabase::database();
    if(db.isValid()) {
        db.close();
        QSqlDatabase::removeDatabase(QSqlDatabase::defaultConnection);
    }
    /* some other exit preparation code may be required here ?*/
    exit(0);  // execution is passed back to the next line following "return app.exe()" in the main.cpp, which is usually the last line so the app quits.
}

The QMutex class does this:

The QMutex class provides access serialization between threads.The purpose of a QMutex is to protect an object, data structure or section of code so that only one thread can access it at a time (this is similar to the Java synchronized keyword). It is usually best to use a mutex with a QMutexLockersince this makes it easy to ensure that locking and unlocking are performed consistently.

... example given here...
Then only one thread can modify number at any given time and the result is correct. This is a trivial example, of course, but applies to any other case where things need to happen in a particular sequence.
When you call lock() in a thread, other threads that try to call lock() in the same place will block until the thread that got the lock calls unlock(). A non-blocking alternative to lock() is tryLock().

See also QMutexLocker, QReadWriteLock, QSemaphore, and QWaitCondition.

Most applications written with Qt begin a single thread when the "exec()" function is called:

QApplication app(argc, argv);
app.setQuitOnLastWindowClosed(false);
... set up the application, open databases, display user interface ...
return app.exec(); ... start the event loop within the user interface

This thread is given its own stack by the OS and starts its own event loop. The event loop runs continuously and responds to interrupt requests by placing the event in a fifo que.

Most coders who write applications (with Qt or any other API) usually never concern themselves with (and may not even be aware) of threading or mutex and locks. We are not too far removed from the days of a single CPU. With only one CPU creating more than one thread per application made little sense, because a) the same CPU handles all threads, and b) threads have house keeping code which takes cpu cycles and slows things down. The first multi-cpu "supercomputers" were actually lots of single core motherboards hooked together by network wiring and controlled by a single cpu which did the division of labor and housekeeping. Only programs which lent themselves to Taylor expansion series, for example, benefited speed-wise from assigning each term of the series to a single CPU. Later, manufacturers began putting more than one CPU on a motherboard. It is not unusual to hear of someone running a 4 core or 8 core or sometimes a 16 core PC. BUT, if the program doesn't make allowances for creating a thread for each core, beyond the one it is running on, only the OS uses the extra cores when you run more than one program at time. So, I can start a db SQL query from my PGAdmin III interface to my PostgreSQL9.0 database, and while it is chugging away in the background I can get back to watching an online NOVA video. Life is good!!