Kernel Patch and Compile

[manly]

I've installed both the multimedia kernel and it's source, and everything seems to be working properly. How can I test performance of the multimedia kernel vs. the regular kernel? I'm not really sure what the mm kernel changes, so I'm lost as to what would be a good test. Encoding mp3's, Quake FPS's, video editing? Tips would be appreciated.

 

I would also like to recompile the multimedia kernel for my system (a celeron 433 :-P). I assume that it's not much different than compiling a standard MDK kernel. I would also like to patch the kernel with the suswap patch found at http://fchabaud.free.fr/English/default.ph...usp&FILE3=Index. The site lists many kernel versions... which one do I use? Also, is there an easy way to back up the source to the mm kernel before I patch it? Or would I have to reinstall the source?

 

Thanks,

Andrew

[wrc1944]

Andrew,

Here's an excerpt from man gcc 3.2.2. You could rebuild the multimedia kernel srpm, and specify the appropriate target for your Celeron 433. I'm not up on which one it would be, but it would be one of the Pentiums or i586, or i686, as Celerons are basically Pentiums with a smaller cache. I assume you are using Mandrake 9.1, and you might have already compiled for your kernel appropriately by default (i586) for the celeron. The command would be something like:

 

rpm --rebuild --target (your cpu) kernel-multimediaxxxx.src.rpm

 

I don't believe the standard Mandrake /usr/lib/rpm/rpmrc file has Pentium optflag lines- the celeron 433 might be i686 or pentium2. You would need to do some research to be sure what architecture to use. Since the gcc 3.2.2 compiler has those pentium options built in, you could add a line and flags to the rpmrc file, and then specify it as the target when you rebuild.

 

-------------------------------------------------------------------------------------------------------

These -m options are defined for the i386 and x86-64 family of comput-

ers:

 

-mcpu=cpu-type

Tune to cpu-type everything applicable about the generated code,

except for the ABI and the set of available instructions. The

choices for cpu-type are i386, i486, i586, i686, pentium, pentium-

mmx, pentiumpro, pentium2, pentium3, pentium4, k6, k6-2, k6-3,

athlon, athlon-tbird, athlon-4, athlon-xp and athlon-mp.

 

While picking a specific cpu-type will schedule things appropri-

ately for that particular chip, the compiler will not generate any

code that does not run on the i386 without the -march=cpu-type

option being used. i586 is equivalent to pentium and i686 is

equivalent to pentiumpro. k6 and athlon are the AMD chips as

opposed to the Intel ones.

[aru]

I've installed both the multimedia kernel and it's source, and everything seems to be working properly. How can I test performance of the multimedia kernel vs. the regular kernel? I'm not really sure what the mm kernel changes, so I'm lost as to what would be a good test. Encoding mp3's, Quake FPS's, video editing? Tips would be appreciated.

 

Since the multimedia kernel is just the mandrake kernel with mandrake-particular preemptive and low latency patches, here is an excellent review of what are and what do each patch to your system:

http://www.linuxdevices.com/files/article0.../rh-rtpaper.pdf (here is the google-HTMLed version)

[manly]

You could rebuild the multimedia kernel srpm, and specify the appropriate target for your Celeron 433. The command would be something like:

 

rpm --rebuild --target (your cpu) kernel-multimediaxxxx.src.rpm

I have always previously installed the kernel source into /usr/src/linux-xxx, and gone through the process of make menuconfig, make dep, etc.... This allows me to remove modules, compile specific modules into the kernel, etc. This (obviously) take much more time, but will it produce a faster kernel than rebuilding the rpm?

 

The other thing is that if I want to apply the swsusp patch, can I somehow apply that to the source rpm? Or am i forced to apply it to the source in /usr/src/linux-mm ? Will that even work? The links on the swsusp home page seemed to be very version specific...

 

Aru: Thanks for the link. A great read :-)

[wrc1944]

Andrew,

As I understand it, you get better performance increases by recompiling your apps for your cpu and architecture rather than the kernel. The reason is that generally less than 1% of the time is spent in kernel activity, and most is spent in user with the specific apps you are using. Thus, any performance increase gained by recompiling the kernel is hardly noticable. Of course I do it anyway, as I'm pretty obsessive about performance.

 

In the case of a celeron 433, you will get far more performance increase by simply replacing it with a Pentium of the highest class your board will allow than any amount of recompiling software will produce. Most boards with celerons will take faster pentiums also. You can pick up used or even new PentiumIIs or IIIs dirt cheap on ebay. You could also overclock the celeron- as I understand it, some of them do overclock very well.

 

As for recompiling your linux kernel, go ahead and do the srpm, and your apps, and I did XFree86 for athlon-xp, which seemed to help. Since the Mandrake kernel is highly modularized anyway, I've found very few items worth removing, and it is very lean to begin with. The talk about the Mandrake kernel being bloated IMHO is a myth. You might find a few items you don't need compiled into the kernel, but it's probably not worth the time doing it. Having lots of kernel modules in /lib/modules doesn't mean the actual kernel image in /boot is bloated- they are only accessed as needed. That's the advantage of a modularized kernel.

 

As for patching a kernel srpm, aru will be able to give far better advice than I can, as I've only patched regular vanilla source kernels before. I googled for the patch you wish to apply, and among other things found the exerpt below you might be interested in. Unless you really need it, you might considered not using it, and just using the multimedia kernel as is, unless you upgrade your cpu in which case then you could rebuild the srpm easily for the new architecture. I would see what higher cpu the board could take first, if performance is the main issue.

 

"The swsusp patch is not ready for prime time, and may also not be part

of ACPI suspend eventually, but the ACPI developers _are_ talking

regularly with Pavel Machek about it, and it seems probable that a large

part of swsusp will eventually be incorporated into ACPI."

 

wrc1944