The current practice of replacing the VM and scheduler with those that are ad-hoc benchmarked on the LKML is unsafe and will cause definite stability problems for users of gentoo-sources. Patches such as -rmap, preempt, and low-latency should be optionalized through the use of USE flags. Additionally, none of the additional options in the kernel should be enabled at all. It should be up to the user to enable items in the kernel config that are added by the patchset of gentoo-sources. This is currently not the case. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Don't think I agree with you, but I'll pass the bug to our kernel devs.
go away, I don't like you. but seriously... every major linux distribution at this point uses O(1) scheduler, and preempt, and most use rmap... I have dropped rmap from the current gentoo sources development for some of these reasons, but believe me NOTHING is done ad-hoc in creating the gentoo-sources, generally a new gentoo-sources has at least a 1 month testing period as lolo-sources, and another several weeks -1 month of testing in unstable before it is released as a final stable gentoo-sources.
hehe i concur love ya work Lostlogic
I tend to agree. Is there a chance Gentoo can make its generic, ie; gentoo-sources, kernel more vanilla, and have the additional (unstable, untested, new, etc.) features existing in a different kernel? As someone who is attempting to replace binary distributions on small servers with Gentoo, it's rather unnerving knowing that there are potential scheduling issues on the horizon.
OK, lets reopen this for discussion... (more to be said after re-assigning)
Ok lets talk about this. Currently we have created and plan to maintain gs-sources "gentoo-stable or gentoo-server sources" this package will be designed for those where the utmost in interractive performance isn't critical, but stability IS. Does that satisfy the goal tha tyou are looking for? The gentoo-sources are spefically designed with interractive performance in mind, that sometimes comes at a minor cost to stability, but gentoo is all about custom performance and such. Thanks.
A workstation and server kernel config. I think that's a great idea. In fact I'd like to begin testing this on a server I have here alongside lolo-sources. I note in the ebuild for the latest gentoo-sources is an explanation of KERNEL_EXCLUDE=; is this a reliable means of removing certain patches, or do some of the patches depend on others by any means?
Ok, that sounds like a great idea, but it looks like the "patch first" mentality has already taken hold. From the gs-sources ChangeLog I already see; - Preempt added - Low Latency added While these patches are somewhat extensively tested, they haven't been tested/proven enough to be included in the currently stable kernel tree. Are they really ready to be considered server grade, or could servers live without them until they've been put through the wash a little more? My ideal for a "stable" kernel is to patch it with as few updates to the vanilla tree as possible and leave it at that.
The 'gentoo-x86 kernel team' has just been completely reorganized... we are discussing and preparing new sets of goals for each of the x86 kernels in portage and will keep people up-to-date KERNEL_EXCLUDE is limited as you divined by the dependence of patches on eachother. For my server I actually am running a HEAVILY excluded version of gentoo-sources, but still including o(1), preempt, and lowlatencey. These patches (in my opinion) are heavily tested enough to be included in a server grade kernel. 2 of the three have been accepted by Linus for 2.5, and RH, SuSe and other distros also use O(1) and preempt in their kernels. As for a "patch-first philosohpy" we are working hard as I've said to give gentoo users high kernels that are as feature rich as possible while preserving stability.
well, we will definitely have a stable desktop/workstation branch & a stable server branch. then we will also have a unstable (read testing) desktop/workstation & the same for server. this will allow for a user to test/use the latest/bleeding edge stuff in unstable branches and hopefully provide a more solid sane kernel in the stable branches for those who are in production enviroments. but *first* i am cleaning the current lolo/gentoo-sources and will build from there. i will have pre5 of lolo based on this and out later this week. i am also looking to how we can get a fixed gentoo-sources 2.4.20-r2 released soon thereafter.
this was fixed in gentoo-sources-2.4.20-r2 Jay
