SMP works

I reported about the kernel crashing when I plug in a USB drive, and rodin.s has the same problem:

I compiled a uniprocessor kernel, and it did not crash:

I decided to experiment with the SMP configuration choices. A little while ago, including the 2.6.30.x kernel that I compiled for Puppy 4.3.1, I configured with SMP enabled, but with these two disabled:

[ ] SMT (hyperthreading) scheduling support
[ ] Multi-core scheduler support

But people kept telling me that they should be enabled, so for the 2.6.32 kernel used in Wary, they are.

Well, guess what, I have just tried with those two disabled, and now I have been plugging and replugging a USB pen drive and just can't get the kernel to crash.

It is probably only one of those that is the culprit, but I will leave it at that. The next Wary will have SMP kernel but with those two items disabled.

You still get SMP support. My Intel i3 CPU is recognised as having 4 cores, and mkquashfs does its thing much faster than with the uniprocessor kernel.

Posted on 27 Aug 2011, 10:32


Posted on 27 Aug 2011, 14:58 by BarryK
2.6.32 smp
The PET (29.1MB):


Posted on 27 Aug 2011, 24:26 by rodin.s
New Wary
I am waiting for new Wary and I hope that it will work for me as well.

Posted on 28 Aug 2011, 6:18 by GCMartin
Hardinfo reports
I have noticed in the past, that when I run HARDINFO on certain distro, some of its analysis does not span the multiple cores as I would have expected.

Is there any possibility that either of the parms you leave off restricting the ability of the system to "spread" application threading over the existing CPU and their hardware threads?

Please understand that "I am NO expert in the OS+kernel area".

When I have the CPU meters on screen and run
hardinfo -r
I can readily see processor loadings

Posted on 29 Aug 2011, 12:20 by BarryK
More SMP success
This is very interesting. I am using Wary 5.1.4 with the SMP kernel configured as described in the first post above.

As well as it no longer crashing when I plug in a USB drive, Abiword now starts up displaying the entire layout -- previously it would only display part of it's page layout initially.

And it gets better... previously I was having a scrolling problem with GTK applications. I would click above or below the slider-widget in the vertical scroll-bar, and the window would jump two window-heights. I was getting this in ROX-Filer, Geany and SeaMonkey. Now it is behaving.

One of those scheduling options throws a monkey wrench into the works.