Kernel questions: shouldn't I get the latest kernel? how?

[Potatohead]

Hi gang, back at the Sid grill after some heavy distro hopping..... Anyway, can anybody help me solve this:

- If an up-to-date system is the best security measure, should'nt I have the lastest available kernel?
- I read that "the older kernel runs cooler". Any more info on this please?
- Any hints on installing (and/or building) kernels, apart from the info in the wiki?
- I like systemd. Yet the versions of LinuxBBQ that have systemd use slightly older kernels. is this because not all functions of systemd go well with the BF scheduler?

Lots of questions, I'm sorry guys. If some one has a answer, idea, suggestions: please post them. Thanks.

[dkeg]

Hi Potatohead, it does seem the newer kernels run a bit hotter, I believe that is why MB is building the spins with those older, cooler kernels. Out of my area of expertise as of why. I did notice a bit of a difference. From normally running around 41-41F to 45-48F. Seemed a bit better since I installed the rc kernels. Any user at anytime can upgrade the kernel. As far as security, each kernel gets the necessary security updates, not just the latest. Currently I am running 3.10-rc7 pae. I just searched for it

Code: Select all

#alias for apt-cache search
search pae
or
search kernel

then insatall the one you want and reboot. I think dura has a thread on cb for building kernel's I believe.

[machinebacon]

Dkeg speaks wisdom. The heat issue is the reason why the slightly older kernel is set default in newer releases. doesn't impact systemd, btw.

[ivanovnegro]

What they said and also, if you make regular dist-upgrades in the future you should have a newer kernel installed. You can always decide to use older ones or to use the newest and even purge unneeded kernels.

IMO Baconface decided correctly and on my own rig I still use 3.2 because everything above from Debian's repo runs crazy on my machine but the Towo Siduction kernels that also are included in many BBQ spins run just fine.

[Potatohead]

Thanks all. Is this a Debian-specific thing? I'll see which kernel is in my Arch install... But anyway, I'll go with the "cool" kernel for the BBQ (a cool BBQ???? ;-) ;-)

[ivanovnegro]

Is this a Debian-specific thing?

Not necessarily but who knows. Debian uses very generic kernels not always optimized for the desktop.

[Potatohead]

@ivan - thanks. I saw @ the gentoo forums the same discussion:

Long Term Stable kernel vs Newest? I prefer to use the Long Term Stable (LTS) kernels rather than the newest kernel. I am wondering if I am the only Gentoo user that feels this way.....The main reason I use LTS kernels is, I want a kernel that is well vetted........ I prefer the LTS kernels because there is a wider source of vetting, When done properly, all distros send there confirmed bugs upstream. So Gentoo, RedHat, SUSE and Ubuntu all send there bugs to the kernel developers and these bugs are dealt with with no mater which distro discovers the bug. The only drawback is delay that happens because of this extended vetting process. By this time, the head of the Linux development has moved on and introduces new bugs into the source.

My main rebuttal, the the objection that LTS kernels don't have the newest features, is that I usually don't need the newest features.........If I were to purchase some newer hardware, I would consider switching kernels if it were required for the newer hardware.....

Basically the discussion was that this poster is right.

TL;DR - older kernels are fine.

[ivanovnegro]

^ Exactly. I think the same. And 3.2 is LTS used in Debian Wheezy and Ubuntu 12.04 LTS e.g. I think.

[bizcuit]

As usual ... late, as usual, won't let that stop me from babbling a bit.

An updated Sid system doesn't necessarily = uber secure. Though am of the opinion even with a poorly config'ed gnu/nix system you're still MUCH better off than the majority aka: Window$ users ... both becuz as we all know Linux is dachit. Plus if you've migrated to Nix you presumably like techie type stuff and thusly are armed with more knowledge about tech than many of the pointy-clicky crowd. ;)

Though kinda obvious that packages in unstable haven't been tested as long as stable yada. So there's bound to be some buggies crawling around. Personally don't consider it much of a problem w gnu/nix though, shrugs.

Like you + others have said and agree ... Newer kernel doesn't necessarily translate to better. Recently become a bit disillusioned with the guy who puts out the Liquorix kernel too. Installed one of the latest ... and had heat issues. Wasn't the horror stories I've heard of people being able to cook eggs on their laptop. Really wasn't that bad but fan came on, stayed on more often than I liked and the exhaust being vented was hotter than I preferred.

Switched to an almost same version of Siduction kernel and those minor heat pita's went away. The guy who maintains the Liquorix kernel applies a buncha patches and tweaks to jack up the kernel. Natural results being it's going to use more power and run somewhat hotter. Guy obviously knows hiz stuff me thinks. Towo ... the dude that maintains the Siduction kernel does many of the same tweaks himself. Though minus the BFS ... and whatever else.

"apt-cache search linux-image*" Install linux-image and linux-headers, work your way through until ya find the one(s) you like the most. Ok ... end babble, hope ya'll are having a good dy/nt. Vllbbq! :)

[machinebacon]

I might add something interesting here:

usually the BBQ comes with a default kernel (recently an older/colder one) and non-PAE (for i686)
If the user wants to have rolling kernels (uhum!) he/she can apply following command:

Code: Select all

ins linux-headers-siduction-686-pae linux-image-siduction-686-pae

(for example, to get a rolling PAE kernel on 32bit)
Be aware that sometimes there are weekly or two-weekly revisions, so if you have a slow network, think twice.

[bizcuit]

^ HA ! I'll see your add Machine and raise you 1 babble edit ! ;)

More opinions on this subject follow w the starting disclaimer " I AM NOT A NIX KERNEL GURU ... AT ALL" Relatively new to the process myself. Still going to babble about it anyway.

Do it the Debian way ... you'll see folks saying extract kernel sourcecode to like /usr/src etc and to compile it all as root. No need ... use fakeroot imo and go ahead and do it in a directory in your /home/username. More on why I think it's better. See #1 below:

1. After the compilation is done you end up with a couple handy .deb packages. One linux-image + one linux-headers ... You can install them with dpkg etc or with friggin Gdebi or however and removing them easily the same way(s). Those packages are portable. Slap the suckers on a zip drive and carry with you if ya want. Doing it with make install to me isn't as convenient or clean. Getting rid of them may end up being more involved ... With the Debian way, was no muss, no fuss "sudo update-grub" was done automatically when I installed the new kern. Though ran update-grub again ... just to make sure.

2. Depending upon which distro or kernel you're using. Yes ... common sense dictates that you can get some decent performance boosts by customizing a kernel. Some of the low hanging fruit for many kernels.

Default i/o scheduler ... I went w cfq ( which is what Siduction kerns use default.) Rather than the bfq aka: bfs ( liquorix + etc.), lowering latency, jacking up the timer interupt frequency to 1000Hz ( < which both Liquorix and Siduction kerns have default.) Many distro's ... esp conservative ones have it set to 250Hz. Get rid of all the stuff under the Kernel hacking section of "make menuconfig" Highlight line ... press n key to remove it from the .config file.

Update: Note ... Cfs ( completely fair scheduler) and bfs ( brain **** scheduler) are cpu schedulers, whereas CFQ and BFQ are disk schedulers. They are totally different things. Assumed CFQ = CFS it doesn't and BFQ = BFS, nope they don't. Ya know what they say about assumptions ... dammit ! :P Was/am dorking around with the bfs patch and so while doing homework discovered the differences above. Am going to try out the bfs though ... eventually, shrugs.

There's plenty of other stuff you can trim out or tweak to hearts content. Depending upon how much time you want to spend digging around it kernel settings blahblahblah. Did mention am not the nix kernel ninja right ? Get too jiggy with removing stuff from the .config file you're using to compile a kernel and you can definitely bork the resulting kernel ie: Sucker wont work ...

Random biz tip: Copy/examine the .config file for your installed kernel. You can find it in /boot ... open thunar/etc go into the /boot directory and you'll find the .config file there. Make a copy + paste it into wherever and open it in a text editor to see what kern configs that kern is using. I used the Siduction kern and a Liquorix kernel .config's to compare them and see what config options they use.

In fact used the Siduction .config file as the basis for the one used to compile the new kernel. Though tweaked several other things to be what I preferred.

3. Not like it's a big deal ... You compile a kernel and it doesn't work right. Just reboot .... boot a working kernel, get rid of the borked one and if feel like it ... try again. So about the worst that'll happen is you'll have invested some time without a gratifying payoff.

Misc babble on the topic :

Went ahead and compiled the 3.10 kernel last night from kernel.org. Only been dorking with it for a few hours now. "SO FAR" ... yes it's an improvement for me. Boots faster, shutdown faster, runs cooler and is definitely more responsive, got to tweak a buncha features-config options I wanted different than default, got new features added that aren't in older kerns YET anyway. Again that depends on your distro(s) of choice.

"SO FAR" working really well ... Though haven't tested everything yet either. Might plug something in and BAM doesn't work ... nope got too jiggy with the kernel configs cbizcuit ... DAMMIT MAN !

Some misc factoids and babble databits about the topic.

* Kernel compile time = 40mins. ( on an amd quad-core laptop. Elected to use all 4 cores during the process w with the -j flag ... "-j4" Rule of thumb is number of cpu cores you have + 1 . I have 4 on this lappy so I went with -j4.)

* Size of the directory I created to do the compile in my /home/username, after the compile was done = 1.6gbs

note: A good reason to deselect all the stuff in the Kernel hacking section of the .config file you use. Believe that stuff is meant for kernel developers anyway. People that want to debug the nix kern-etc. Supposedly if you leave all that crap selected the build directory will end up being GIGABYTES BIG as in 6+gbs ! Clearly it'll also take A LOT longer to finish compiling the sucker too. While researching saw enough people mention it 2 heed the advice/warning.

* Final sizes of the .deb packages created:

linux-image = 33.6mbs
linux-headers = 8.8mbs

End result ... so far working very well. Got some noticeable performance benefits + it makes you feel like a MegaL33T nix ninja. When I run "uname -r" in terminal I get to see "3.10.0-custom" :P Guess time will tell if continues running well ooooorrrr I might eventually find out I screwed summin up, shrugs. Well ... hope this helps or was of interest to somebody. Think you should give er a go. Always heard it's a nixer rite of passage. You aren't ... AND SHALL NEVER BE a true g33k. Until you successfully compile a nix kernel !*!*!*!

Vllbbq! :)

[pidsley]

OK, if we're talking about building kernels, I will go ahead and (again) plug http://kernel-seeds.org/

This web site provides "kernel seeds" -- config files that are good starting points for new kernel builders, and detailed instructions on how to configure the kernel for your hardware: http://kernel-seeds.org/working.html

A note about the timer interrupt frequency: 1000 Hz is fine for older hardware like you have bizkit, but if you have more than two cores I think it is not a good idea to set this abover 300 Hz.

Timer frequency should be limited to 300Hz for CPU's with more than two cores. Timer frequency should be limited to 1000Hz for dual core processors. The reason for this is the timer frequencies have an additive effect: each core runs at the frequency given, and that can increase the internal frequency over 3000Hz. That can cause boot failure, driver failure, and erratic operation, depending on the system.

The lowest "low hanging fruit" in kernel building (in my limited experience) is that it allows you to build what you need into the kernel itself and allows you to boot without an initramfs. This significantly reduces boot times (at least on my hardware). Of course, you lose all this advantage if you factor in all the time you will waste configuring and building kernels :)

More pointless babble -- if you rely on a wireless connection for your internet access, making this work in a custom kernel can be a bit of a challenge. Wired networking seems pretty simple (if I can make it work, it's simple) but wireless, not so much.

[bizcuit]

Lmao ... still editing and getting rid of typos ! Arghhhh ... though good thing. Means I'm still around to thank Pidsley for the good info. Will have to check it out ... thanks.


vll! :)

DAMMIT ! Babble edit:

Isn't meant in a testy way Pidsley ... Mentioned if you're using a Siduction kernel or Liquorix, then the kern is running @ 1000Hz. This is not old hardware either. It's a AMD quad-core w 6gbs of ddr3. ;) Though agree with you at the same time. Not sure why there's so few kernel config options for the setting. Jumping from 300Hz to 1000Hz seems a bit extreme to me too.

Thought about trying 300Hz ... but figured if Siduction + Liquorix + some other low latency kernels supposedly optimized for a desktop/laptop system .configs are using it ... I'd follow their lead. Sheesh even briefly considered how to custom tweak the setting myself. Nah .... too lazy. Oh well ... again thanks for the interesting kernel resource Pidsley anddddd VLL! ;)

[pidsley]

^ the way I see this, bizkit, is that we have two groups of "experts" (towo and liquorix on one hand, and the Gentoo guy from kernel-seeds.org on the other) who disagree. You and I are noobs who really don't know what we're doing, so I'm not going to argue with you. I will continue to use 300Hz in my multi-core kernels. You can continue to use 1000Hz in yours. I really have no idea what's best.

But I wonder if this might be part of the reason people are always complaining about Liquorix running so hot.

More food for thought. http://forums.gentoo.org/viewtopic-p-71 ... ml#7173566

[bizcuit]

Agree with you and have much respect for old head Gentoo'ers ... Just always heard they tend to know quite a bit about gnu/nix. Not disagree'ing with you either. Was really tempted to opt for 300Hz and yeah JMO ... It's one of the reasons Liquorix runs hotter. Think those few settings mentioned in that babble bk above ( also likely BFS). Plus wouldn't surprise me if he has power scaling set to performance ... So the kernel + cpu(s) are running ballz to the wall. Haven't bothered confirming that last one in the Liquorix .config file though.

Kinda stuff is obviously not so good for laptop ( if battery life is important to X person.) Though no doubt does pep things up too ... and shouldn't "hurt" anything. Most cpu's supposedly far outlive the system they're installed on. End up in the trash still in fine working condition. Though if long battery life is important to someone etc blahblahblah.

I set it to ondemand for mine ... One of the reasons I mostly went with Towo's config as a basis. Guy seems to be more on the conservative side imo. Ahhhh anyway, long way of saying I agree with you. Might recompile and lower that setting. Even though don't consider it a big deal for this hardware, +1's your other sentiments too. Learned enough to be dangerous to myself + poss others. ;)

Also meant to add ... The low hanging fruit stuff I babbled about above are just some of the settings many respected nixers seem to agree are important config settings for desktop/etc "performance". Though a person will have to do some research and play around to find out what works best for YOU/THEM. Personally think it's an interesting subject w some interesting poss's for x enduser. I AM NOT ( even close) 2 BEING AN AUTHORITY on the topic.

Ok ... enough babble and btw. HAPPY 4th of July Pidsley and fellow nixers !!! :)

[Potatohead]

Hey, thanks all you guys. In a few weeks I will have time to fiddle with kernels - I work in education, my wife has a "normal" (LOL) job, so after our holiday at the Mediterranean, she will get back to work and I have 3 more weeks of spare time to paint the house........make a new terrace........renovate the kitchen........ compile new kernels for my Debian, Arch and Gentoo installs.

First things first! ;-)

[wuxmedia]

didn't need to google power scaling (thats like climbing, isn't it?)
but this;
http://www.urbandictionary.com/define.p ... ng%20fruit
i'd never heard of that. 8)

[bizcuit]

^ Lmao ... :D

Ya welcome Potatoehead ... sounds like you've got a full plate atm. Hope you + Mrs's enjoy the trip. Thought about doing a how to on it. At least how I prefer doing it. Don't really feel qualified on the topic though. Think ... for most people it's a non-issue. If you want a high performance kernel ... Use a distro that uses them or if/when poss install one of them from xyz-distro's repo's.

Machine ... not surprisingly, already takes care of that OOTB with Trollinger, am assuming it's much the same for other BBQ releases ( Siduction kernels)? Those kerns are already config'ed more for performance, using cfq as the scheduler, already have low-latency and timer interupt freq @ 1000Hz. I'm still going w the 1000Hz setting, every supposedly "optimized" for desktop/laptop kernel I've come across all use that setting.

So am using it and the compiled kernel still runs slightly cooler than the default kernel I was using. Nothing spectacular though. Haven't seen any irratic behavior or freezes ... so far anyway. Could also be any number of outside contributors involved. ie: Newer kernels SHOULD have improvements, security, memory management etc <add endless other poss's here>. Nix kernel 3.10 just went stable not too long ago. Am sure it'll get added to Siduction/etc repo's before too long.

Haven't got a Liquorix kernel installed atm, so not sure how it stacks up temp-wise. Supposedly Damenz adds some 200k lines of code to the nix kernel. What all of that does I have zero idea. Nor saying it's a bad thing ... Guy has alot of nix fans scattered around the interwebz. Have had both good and bad ( noticed pc was running a bit hotter than I'dve liked) with Liquorix kernels. Supposedly as long as your cpu(s) aren't running @ 70+ degrees celsius you're good anyway. Atm this 3.10 kern running cpu(s) are @ 51.3 degrees C.

What am trying to say with all this babble, is for the majority there are plenty of good-easier options for getting a tweaked kernel. Can be some benefits but they aren't likely to be massive compared to just using one of the kernels already optimized for desktop/lappy pcs.

Guessing the main reason is interest or learning purposes. Increased geek street cred, lol ... The benefits of a custom compile vs one someone has already done for you are unlikely to be massive. That's my limited experience and opinion on it. Can also see times when compiling the kernel makes good sense too.

Depends on what/why someone wants to compile a kernel. For me it's the time involved ... Mentioned on an AMD quad-core @ 1.8Ghz per core. Takes me 40-45mins ... Not including the added time of dorking with .config settings, if I don't use the same .config file and/or snatch one from Towo or Damenz. :D

Mentioned that's one of the advantages I think involved with doing it the Debian way. The .deb packages are portable ... Can be installed on other Debian ( or Debian based) OS's easily .. removed easily. Just mainly saying for many desktop enthusiasts, there are other options to DIY kernels. Still though ... I think it's interesting, neat and CAN have uses.

As mentioned there's also the G33K kewlness factor to consider. Bask all ye in my geeky l33tness ! ... Output of "uname -r" ... "3.10.0-custom-build-v2" ... If that doesn't impress somebody I don't know what will ! :)

[dkeg]

I had been running the pae 3.10-rc kernels. No problems, and the running hot issue was a bit better. The other day I started using the 3.10-0 towo-siduction-686-pae kernel. With this no running hot issues at all, running generally at 40-43 F.

[bizcuit]

So ( v 3.10) is already in the Siduction repos ... Yowza, ... looks like Towo works-moves fast. :D

Yep you guessed it ... more ( mainly ignorant) babbling about the nix kernel and/or compiling the sucker.

Still mostly writing it off as a novelty for most nixers. Estimating it'd take literally months to dig through, research ... 1/2 understand the subject to the point that a person would be reasonably competent in the matter. Still sticking to the opinion someone is probably better off sticking to the kerns available in their distro of choice ( or a compatible distro's) repo's.

Summin like 3,000+ config options in the dang .config file. Some of the ones mentioned above in the low hanging fruit babble likely are considered important considerations. If someone is going to fiddle and mix-match config options. Again ... just saying the time involved vs the potential benefits is questionable. Esp compared to using a pre-rolled/tweaked kernel.

Not sure if I have the fortitude to bother with digesting the topic.

Atm using a 3.10 compiled kern with 300Hz set as per Pidsleys outlook. Yep ... seems to be working fine. So is the dang 1000hz kernel. Believe some apps require 1000Hz, though to me seems a bit wasteful jumping from 300 to 1000hz. Am certain there are ways to set a custom value. Looked into a bit ... nothing satisfying or conclusive so far.

Not sure if am for or against compiling your own kernels at this point. Off the top example, while going through config options, thought hey, I've got an AMD processor and chipset, therefor I shouldn't need any of this Intel crap. Errrrrr ... wrong, output of "sudo lspci -k" shows the friggin audio module being used is ...

Audio device: Advanced Micro Devices [AMD] Hudson Azalia Controller (rev 01)
Subsystem: Toshiba America Info Systems Device fb46
Kernel driver in use: snd_hda_intel
Kernel modules: snd-hda-intel

Though I hadn't disabled that option in the .config file anyway ... Sighs.

Here's a decent looking URL on kernel config options (imo) there. Many cryptic things, lmao ... One that caught my attention in that reference ...

NR_CPUS — Maximum number of CPUs (2-255)

This allows you to specify the maximum number of CPUs that this kernel will support. The maximum supported value is 255 and the minimum value that makes sense is 2.

This option is purely to save memory; each supported CPU adds approximately eight kilobytes to the kernel image.

Though the potential savings are not friggin spectacular by any means ... Who da heel has a system with 255 cpu(s) in it ?!?!?? :P I want 2 shake their hand ... just cuz their weird in that case.

Really "tweaking" the sucker imo ... Would require a massive time investment ... end of the day. You might not need 99% of the default config options, though buckle your dang seatbelt in terms of grokking the fecker ! Arghhhhh ! Ok shutting it ... this has become my place to drunkenly babble about nix kernel compilation. Perhaps do it for geek dick waving purposes ? :D

Vllbbq!