Package Details: linux-ck 6.11.10-1

Git Clone URL: https://aur.archlinux.org/linux-ck.git (read-only, click to copy)
Package Base: linux-ck
Description: The Linux kernel and modules with ck's hrtimer patches
Upstream URL: https://wiki.archlinux.org/index.php/Linux-ck
Licenses: GPL-2.0-only
Provides: KSMBD-MODULE, VIRTUALBOX-GUEST-MODULES, WIREGUARD-MODULE
Replaces: virtualbox-guest-modules-arch, wireguard-arch
Submitter: graysky
Maintainer: graysky
Last Packager: graysky
Votes: 459
Popularity: 0.22
First Submitted: 2011-07-22 14:51 (UTC)
Last Updated: 2024-11-26 13:15 (UTC)

Dependencies (14)

Required by (7)

Sources (6)

Latest Comments

« First ‹ Previous 1 .. 90 91 92 93 94 95 96 97 98 99 100 .. 308 Next › Last »

graysky commented on 2016-12-18 10:07 (UTC)

@SuperIce97 @mrkline - Good points about usability and about niche population with aged hardware. I reverted the commit removing native updating 4.8.15-2 without bumping the pkgver since I don't want to rebuild for [repo-ck] since this change has 0 impact to the repo packages.

QuartzDragon commented on 2016-12-18 06:20 (UTC)

@mrkline @SuperIce97 Also agreed! :)

mrkline commented on 2016-12-18 05:29 (UTC) (edited on 2016-12-18 05:35 (UTC) by mrkline)

+1 for bringing back `-march=native`. If you look at what flags are actually passed to the actual compiler (cc1), it provides much more machine-specific information (e.g., cache size, etc.) than `-march=<CPU family>`. As other users have suggested, it seems like there are workarounds for CPUs where it caused trouble. Even if workarounds don't exist, why remove the option from *all* users for the sake of a minority? A simple warning to avoid the flag for the few setups where it causes trouble should suffice.

SuperIce97 commented on 2016-12-17 21:02 (UTC)

Is there anything wrong with the version of your patch before the last commit that removed the native option? If you choose native, it automatically gives you the option for P6 NOPS but it's disabled by default. I think that's a pretty safe way to do it. The help message also has the pretty straightforward message of "Say Y if you have Intel CPU newer than Pentium Pro, N otherwise." at the end, so I believe that anyone who enables Native optimizations would know what to do there. For the issue with Atom CPUs having issues when set to native, you could just add "[causes issues on some Atom CPUs]" to the name of the native option. I don't think this needs to be too complex.

graysky commented on 2016-12-17 19:57 (UTC)

@SuperIce97 - I am not skilled enough to implement the logic for the X86_P6_NOP needed. While true that the native option may pass more tokens to make, if you look at the unpatched Makefile for a selection of core2, they are merely passing march=core2 option[1]. 1. https://github.com/torvalds/linux/blob/master/arch/x86/Makefile#L110

SuperIce97 commented on 2016-12-17 19:53 (UTC)

Also, I noticed that on my SandyBridge laptop, march=native enables a ton more instructions than march=sandybrdige (my CPU is a 2630QM which is a SandyBridge). That means that we are not getting the full potential by specifying an arch vs native arch

SuperIce97 commented on 2016-12-17 19:40 (UTC)

Looking at issue #17 on the gcc patch's github page though, I don't think it would be that difficult to enable native optimizations and just have a X86_P6_NOP as an additional option like tpruzina suggested. The reason I prefer using native instead of the specific arch is because some lower end CPUs (at least with Intel) don't seem to actually support every instruction of their arch for some reason. I used to have a Chromebook C720 with the Haswell Celeron 2955u (I now have a C740 with a Broadwell Celeron 3205u) and I was using the Haswell kernel until it decided that it wouldn't boot (not sure if a change in the kernel or gcc caused it; it was a long time ago and I was too lazy to hunt down the issue) if I compiled it with Haswell. With native on the other hand, the kernel worked just fine. Would it be possible to reimplement march=native but have the extra configurable as suggested by tpruzina?

graysky commented on 2016-12-17 18:57 (UTC) (edited on 2016-12-17 18:58 (UTC) by graysky)

@nTia89 - I removed it as handling dependencies for newer/older hardware would be too difficult[1]... just select the hardware option that corresponds to your CPU[2] and functionally, there is no difference. 1. https://github.com/graysky2/kernel_gcc_patch/commit/84aad1d8bf5e0c2505b8fb9882394a262a7307e8 2. https://wiki.archlinux.org/index.php/Repo-ck#Selecting_the_correct_CPU_optimized_package

nTia89 commented on 2016-12-17 17:24 (UTC) (edited on 2016-12-17 17:55 (UTC) by nTia89)

@graysky, how does new GCC patch affect "-march=native" users ?

graysky commented on 2016-12-17 16:20 (UTC)

Bump to v4.8.15-2 Changelog: Updated version of gcc patch Commit: https://wiki.archlinux.org/index.php/Linux-ck/Changelog

« First ‹ Previous 1 .. 90 91 92 93 94 95 96 97 98 99 100 .. 308 Next › Last »