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 .. 90 91 92 93 94 95 96 97 98 99 100 .. 307 Next › Last »

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

graysky commented on 2016-12-15 23:51 (UTC) (edited on 2016-12-15 23:55 (UTC) by graysky)

@Rainmaker - I like to use the official PKGBUILD as a template for this one since it minimizes both the chance of errors and my time to keep it in sync. Plus, I think many might not want to have the extra bulk of the headers package since it's only really needed to build modules. Not sure what you mean by split out the config. @BSB6 - It's the holidays people travel... seems to get this this pretty consistently this time of year.

QuartzDragon commented on 2016-12-15 22:51 (UTC)

@BS86 So what? Perhaps there's a good reason for it?

QuartzDragon commented on 2016-12-15 22:50 (UTC)

@Rainmaker I believe that the linux-ck PKGBUILD already does this?

BS86 commented on 2016-12-15 22:40 (UTC) (edited on 2016-12-15 22:40 (UTC) by BS86)

lol - arch still has only 4.8.13 in their official repositories, and no 4.9 - even Manjaro already has 4.8.14 and 4.9.0 in the stable repos -.-

Rainmaker commented on 2016-12-15 22:07 (UTC)

First of all, thank you for being very on top of all updates. If I may suggest 2 improvements: - You can build multiple packages in a single PKGBUILD. Because linux-ck and linux-ck-headers are likely to be installed together, may I suggest merging both packages to a single package. Building multiple packages in the same PKGBUILD is something that, for example, clion does. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=clion. Effectively, it is setting pkgname= to a space separated list. - Could you split out the config? Each time I do a git pull, I need to open up PKGBUILD, and edit the parameters. By having a separate configuration file, I can setup git to ignore that file (with assume-unchanged), which saves me from having to set the parameters over and over.

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