Package Details: linux-ck-headers 6.11.10-1

Git Clone URL: https://aur.archlinux.org/linux-ck.git (read-only, click to copy)
Package Base: linux-ck
Description: Headers and scripts for building modules for Linux-ck kernel
Upstream URL: https://wiki.archlinux.org/index.php/Linux-ck
Licenses: GPL-2.0-only
Submitter: graysky
Maintainer: graysky
Last Packager: graysky
Votes: 457
Popularity: 0.055433
First Submitted: 2011-07-22 14:51 (UTC)
Last Updated: 2024-11-26 13:15 (UTC)

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:44 (UTC)

A modification I am considering is to have the AUR package provide unmodified config files for x86_64 and for i686 with respect to the gcc patch. What this means is that whenever you build linux-ck yourself, makepkg (or am I assuming your AUR helper) will pause and wait for you to select from the list of CPU optimizations (with default being a simple enter key). This will circumvent the need to modify the PKGBUILD enabled the nconfig option, and subsequent poking around in the nconfig itself. Potentially way faster and easier for the user. 1) How do people feel about this? 2) Will the added interactivity break AUR helpers (I am a pure makepkg person myself)? Example output: % makepkg -src ==> Making package: linux-ck 4.8.15-2 (Sun Dec 18 05:42:02 EST 2016) ... Processor family 1. AMD Opteron/Athlon64/Hammer/K8 (MK8) 2. AMD Opteron/Athlon64/Hammer/K8 with SSE3 (MK8SSE3) (NEW) 3. AMD 61xx/7x50/PhenomX3/X4/II/K10 (MK10) (NEW) 4. AMD Barcelona (MBARCELONA) (NEW) 5. AMD Bobcat (MBOBCAT) (NEW) 6. AMD Bulldozer (MBULLDOZER) (NEW) 7. AMD Piledriver (MPILEDRIVER) (NEW) 8. AMD Steamroller (MSTEAMROLLER) (NEW) 9. AMD Jaguar (MJAGUAR) (NEW) 10. Intel P4 / older Netburst based Xeon (MPSC) 11. Intel Atom (MATOM) 12. Intel Core 2 (MCORE2) 13. Intel Nehalem (MNEHALEM) (NEW) 14. Intel Westmere (MWESTMERE) (NEW) 15. Intel Silvermont (MSILVERMONT) (NEW) 16. Intel Sandy Bridge (MSANDYBRIDGE) (NEW) 17. Intel Ivy Bridge (MIVYBRIDGE) (NEW) 18. Intel Haswell (MHASWELL) (NEW) 19. Intel Broadwell (MBROADWELL) (NEW) 20. Intel Skylake (MSKYLAKE) (NEW) > 21. Generic-x86-64 (GENERIC_CPU) 22. Native optimizations autodetected by GCC (MNATIVE) (NEW) choice[1-22?]:

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 ?

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