Announcement

Collapse
No announcement yet.

Linux 4.1 Brings Many Potentially Risky x86/ASM Changes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Lennie
    replied
    Originally posted by deadite66
    This part is the biggest problem for me, which part of the kernel component to file the bug against.
    it isn't always obvious.
    My first thought would be to point to the kernelnewbies. There list is similar to my thoughts:

    http://kernelnewbies.org/FoundBug

    If that doesn't help they have an IRC channel I believe:

    http://kernelnewbies.org/IRC

    I changed my Phoronix settings, if that doesn't help send me a private message.

    Leave a comment:


  • Lennie
    replied
    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.

    Leave a comment:


  • Lennie
    replied
    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.

    Leave a comment:


  • Notavi
    replied
    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.

    Leave a comment:


  • mctylr
    replied
    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.

    Leave a comment:


  • davidbepo
    replied
    good

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

    Leave a comment:


  • phoronix
    started a topic Linux 4.1 Brings Many Potentially Risky x86/ASM Changes

    Linux 4.1 Brings Many Potentially Risky x86/ASM Changes

    Phoronix: Linux 4.1 Brings Many Potentially Risky x86/ASM Changes

    Another one of the Linux 4.1 pull requests sent in today by Ingo Molnar is for the x86/asm code...

    http://www.phoronix.com/scan.php?pag....1-For-x86-ASM
Working...
X