Package Details: linux-ck 6.11-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.90
First Submitted: 2011-07-22 14:51 (UTC)
Last Updated: 2024-09-19 13:04 (UTC)

Dependencies (14)

Required by (6)

Sources (6)

Latest Comments

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

graysky commented on 2016-12-18 13:42 (UTC)

@artafinde - see my comment from 2016-12-18 10:44 for the example.

artafinde commented on 2016-12-18 12:37 (UTC)

@graysky Can you provide a PKGBUILD (maybe through gist) to see how much interaction will be needed? I personally have to edit PKGBUILD anyway since I'm building with modprobed and BFS enabled by default (and using "-march=native")

nTia89 commented on 2016-12-18 11:43 (UTC) (edited on 2016-12-18 11:45 (UTC) by nTia89)

yes, missing of optimizations without -march=native is my worry! (I know, this seems false but it is true... https://bbs.archlinux.org/viewtopic.php?id=210740) hence, any modification is welcome, even if this mean to press some key my doubt is another: who builds this package from AUR, I imagine, wants the best optimizations overall, so, why "-march=native" is not the default choice?

zerophase commented on 2016-12-18 10:59 (UTC)

@graysky depends on how it's implemented. But, in general if a config file has new additions in a package bump it interrupts kernel compilation till I resolve the issue. I imagine whatever you implement will work with yaourt as well.

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

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