Announcement

**davidbepo** · 13 April 2015, 02:25 PM

good

this seems to be a very important change that can speedup x86 systems

**mctylr** · 13 April 2015, 05:01 PM

Originally posted by davidbepo View Post

this seems to be a very important change that can speedup x86 systems

It is primarily source code clean up, there should be very little difference in the resulting kernel binaries.

The issue is this is the sort of changes that may affect a (relative) small number of systems, older systems with older processor micro-architecture (pre-Core for example), and non-Intel/AMD processors.

The non-Intel/AMD processors may be the largest potential victim, as they (i.e. VIA, DM&P, Transmeta) are aimed at low-end or embedded environments, have a very small number of deployed systems, and so are not as likely to be found in a developer's build / test environment due to their constrained environment (little RAM, slow speed, missing storage or networking interfaces).

Other things such as quirks in lesser known motherboard manufactures, or motherboards with broken/buggy BIOS/UEFI in systems, could also be affect. As Coreboot developers acknowledge, many low-cost motherboards are released that as long as they work(ed) under Microsoft Windows, then the manufacturers won't fix such BIOS/UEFI bugs.

This changes esoteric parts of the Linux kernel system that are rarely touched, they have a risk of breaking long ago written patches (i.e. affectedly undoing) in an effort to clean-up such code. Many included compatibility workarounds which may not be entirely obvious to even the most experienced developers, including those who made of written the original patch years, or thousands of commits ago.

**Notavi** · 13 April 2015, 08:36 PM

Donating hardware to kernel developers?

Hmm, I've got an old Via C7-D motherboard / cpu kicking around from a former home web-server box (it was a nice low-power server back in its day).

I wonder if there's a way I can donate it for testing this stuff.

**Lennie** · 14 April 2015, 06:03 AM

Originally posted by Notavi View Post

Hmm, I've got an old Via C7-D motherboard / cpu kicking around from a former home web-server box (it was a nice low-power server back in its day).

I wonder if there's a way I can donate it for testing this stuff.

You just compile the kernel and run it on your machine and report problems if you see them. I would try 4.0 first, when you have it working try the newer 4.1

Maybe you'll be asked to 'bisect'.

I've done this also many, many years ago.

It takes some of your time. When you've done it before, something like 5 minutes of your time every time there is a new RC release (and you don't have to do it for every release), the computer does most of the work.

It ensures the newer kernels will work on hardware you own.

Steps:
- download/extract kernel or download patch and apply patch (although maybe you want to use git)
- copy existing kernel config, usually in /boot/config-[version]
- use that config as the base of the new kernel config and create a new configuration for this kernel
- compile
- install (basically copying it to /boot and /lib/modules and updating grub config)
- reboot
- if it failed, turn off, reboot with older kernel and send an email or report it on bugzilla.

This will help find problems with just running a kernel.

Obviously, if you want to help find regressions in performance, you'll have to run some tests.

How about the Phoronix Test Suite :-) Pretty sure you can also run only the tests you are interested it.

Run and compare to see if there are big problems.

**Lennie** · 14 April 2015, 06:05 AM

Originally posted by mctylr View Post

It is primarily source code clean up, there should be very little difference in the resulting kernel binaries.

The issue is this is the sort of changes that may affect a (relative) small number of systems, older systems with older processor micro-architecture (pre-Core for example), and non-Intel/AMD processors.

I wonder if they are doing cleanups does that mean they'll be doing big changes soon.

A lot of the time with commercial software development, cleanups go before implementing new features, etc.