Following Bug 469686 and thanks to Markos Chandras, the ck-sources tree has been updated in order to :

- Push the 3.9.2 early release,

- 3.8.13 is also out as last release of the 3.8 stable branch.

- no-networkless {3.6.11-r2 / 3.7.10-r1 / 3.8.3} installs should be upgraded because of a couple of security related issues,
- Please note that 3.4.34 users should upgrade to 3.4.43 for the same reason.

About the 3.9.2 early release, please note that :

CK wrote:

There were some fairly dramatic CPU offline code changes to mainline (YET AGAIN!) and the changes to BFS to make it work were fairly significant so there may once again be issues with power off/reboot/suspend/hibernate.

It Is Alreay Very Expensive to be Fair! => It is going to be even more expensive when being able to tune fairness

I make no doubt that all of us here around reading this thread, are well aware of the fact that ensuring fairness costs a big and highly variable amount of cpu time, this leading to *high* and highly variable latencies. And that it is almost certainly one of the most important reason why we do not want the CFS.

Now, from whatever project's management standpoint, we also know well the now *extreme* cost of offering the possibility for a system to sometimesmore or lessignore THE boolean quality / property / characteristic the entire design is based on.
(OK... offering the possibility... without totally ruining the entire system I mean... )

Oh wait! something is still missing in order to completely end the tragedy... the main attraction for the show I mean :

Offering the end user a knob for adjusting a desired percentage of the boolean concept the system is built on !

My post is unfair ? Of course not! It's only 66.6%-fair, which contributes to 50%-granting 99%-eternity to the BFS concept!

Yes, linux-3.9.4-bfs runs very well! (I didn't use linux-3.8-bfs) And the stable-queue patches for linux-3.8-ff showed a very beta nature of that release compared to linux-3.9 now. I am very pleased
Time for kernel.org for another new LTS !_________________fun2gen2

so what in essence does this mean ?
currently the kernel is trying very often to ensure fairness which in turn leads to low throughput +/- high latencies ?

In essence ? Well... in essence... things are much worse than that.

1/ You get a whole machine rowing in the direction of fairness.
2/ Because you realize that this is not always optimal, you introduce components capable of rowing in the opposite direction.
Fair enough! After all... why not ?
3/ Because rowing in the opposite direction, requires important efforts (overheads), efforts that will sometimes be thankless.
And of course, the result becomes highly workload dependent.

Speaking of these particular components, it is reported that they appear capable of boosting by up to 15% the performances of some workloads while... damaging others by up to... 40%

4/ OK then, instead of realizing that the implementation of such a component rowing the opposite direction is an error on principle, you imagine to limit the activity of the component with some kind of timeout and because you cant' know the appropriate value for the threshold (of course... there is no appropriate value) and because it is as easy to implement an umpteen user tuneable as hardcoding a value... you :

Leave to the user the belief he can expect a +15% win, leave to the user the risk to drop everything by 40% and... more probably... to screw everything down by an amount of (15-40)/2 = 12,5% !!!

the hardest working load component is the mother of all work, the (singular) server. Any time 'mom' is not continuously working her little digital a$$ off to keep all those kids fed, you have a performance problem on your hands, the entire load stalls, lives and dies with one and only 'mom'.

As long as no one volunteers for maintaining and Greg K-H cannot maintain more than 2 LTS concurrently, I'm afraid you'll have to wait for 3.0's EOL before enjoying a new LTS branch.
That is to say october 2013, in other words... 3.12 ?_________________

I've just been looking at the 3.11 radeon drm patches, looks like they finally added a good dynpm implementation. Some of the user replies there suggest it does as good a job as the windows binary driver.

Just in time for summer to have already ended... when I *want* my computer to be a space heater again

Note the *BAD*gran_size messages. I made no changes in the .config from 3.9.2 to 3.9.7; I ran make oldconfig and answered no the the 'NEW" stuff [BFQ and the RTC options].

The memory is good, there is no hardware problem. I can boot to 3..9.2 with no errors, but 3.9.7, built with the same .config, yields the above. What else, other then BFQ and the RTC options, could be different and cause the errors? I can eliminate the errors by manually specifying mtrr gran size and chunk size 512M on the boot line, but it effectively causes loss of use of 500MB of memory, so that is certainly not desirable.

I'm not sure if it is the same, since I don't know if he was using 3.9.2 previously with no problems. It does appear to be related, though, and after more research I see that people have been noticing it since 3.9.5.

3.9.7 isn't a must for me, so I guess it would be most prudent to wait for 3.10, since Linus is throwing profanities around to get the code right on that one.

All kidding aside, it looks like the patches will go into 3.10, so rather than go crazy patching manually, I'll just wait.

Interestingly enough, as an experiment I downloaded a 3.10 source tarball from LKA and patched it with 3.10-sched-bfs-440.patch

Then I compiled it with the current options and the error does not exist. I don't know what that means; either the issue is solved for 3.10 [and the 3.10.x ck-sources will also be OK], or it was present only in the ck-sources package for >3.9.2, or the issue is caused by some other patch that is present in ck-sources-3.9.7.

Interestingly enough, as an experiment I downloaded a 3.10 source tarball from LKA and patched it with 3.10-sched-bfs-440.patch

Then I compiled it with the current options and the error does not exist. I don't know what that means; either the issue is solved for 3.10 [and the 3.10.x ck-sources will also be OK], or it was present only in the ck-sources package for >3.9.2, or the issue is caused by some other patch that is present in ck-sources-3.9.7.

You mean you downloaded a 3.10.2 ?
If the problem you experimented is the same than the one I had pointed to, nothing abnormal in the fact that 3.10.2 is OK with that. The problem was fixed in 3.10-rc7 and the fix went backported to 3.9.8

As far as gentoo is concerned, 3.4.54 and 3.9.11 should be on their way to portage._________________

As far as 3.10 is concerned... mhhh... I have experienced multiple problems with this branch. Mainly ACPI centered.
And considering I do not quite like experiencing ACPI troubles at this time of the year...
Moreover, inferring the -rc grade of first 3.10 stable from Greg's comments and understanding he would backport less than a tenth of his 200 patches on 3.10.1...
Well...
I'll wait for 3.10.3 before coming back to work on 3.10_________________

Moreover, inferring the -rc grade of first 3.10 stable from Greg's comments and understanding he would backport less than a tenth of his 200 patches on 3.10.1...
Well...
I'll wait for 3.10.3 before coming back to work on 3.10

Isn't it better to wait for 3.10.6 or something? Let me explain: Greg for long is angry about the BETA quality of .0 kernel releases. In the last discussion it turns out: Kernel devs fear Linus rejecting code in the late run of a release. They hold back important work. Slowly it then gets included into releases of .1 .2 and .3. But these patches are not anywhere tested at this point. This may lead to the fact the very first stable and tested kernel is a point.six

I'm following newest kernel releases for quiet a long time now. I would surely get a rich man if I could bet about it: Also if one release gets stable quality at point.five and two out of ten get stable at point.seven or eight, in the long run I won my bet._________________fun2gen2

You'll certainly have noticed than, since I maintain this package, I've never rushed on early releases and essentially concentrate on high release numbers. You'll certainly have noticed as well the color code I use when announcing version bumps.

I think that the gentoo's sys-kernel/ck-sources is the only package offering high release numbers with the ck patchset. That is it's originality, I leave to others the passion of high version numbers. (no disrespect)

I think that 3.9.2 is the earliest release I have made and this was because I knew that Ant P. needed something to replace his non-working 3.8

This time I will target 3.10.3 only because... I expect being far away from keyboards in August and, as a consequence,... be back in 3.10.7 times.

Because there are users of the ck-sources package who believe in the virtues of rolling releases, who are eager to test new versions, and that is also nice, I just feel I could not abandon them without biscuits until 3.10.7 is out, could I ?

ulenrich wrote:

This may lead to the fact the very first stable and tested kernel is a point.six

Hmmm... This can also make so a 3.9.7 shows regressions toward a 3.9.2...
This probably "because this time we'll do it right"._________________

Isn't it better to wait for 3.10.6 or something? Let me explain: Greg for long is angry about the BETA quality of .0 kernel releases.

As rc versions come packed with new features, releases like .0 can be problematic in terms of stability; after a few releases, quite some patches / fixes have landed to fix the introduced bugs and things become more stable. For this reason, on Gentoo, we stabilize the end of a branch (eg. 3.8.13 stable, 3.9.11 to stabilize very soon); out of branch ends available, the versions near the end of a recent branch look the most stable to us.

ulenrich wrote:

In the last discussion it turns out: Kernel devs fear Linus rejecting code in the late run of a release. They hold back important work.

Yes and no; some developers also end up being late with their changes, so they don't make it in time for the rc kernels and rather push things through to stable. They (Linus and Greg) are putting an end to this style.

aCOSwt wrote:

You'll certainly have noticed than, since I maintain this package, I've never rushed on early releases and essentially concentrate on high release numbers. You'll certainly have noticed as well the color code I use when announcing version bumps.

Good idea.

aCOSwt wrote:

This time I will target 3.10.3 only because... I expect being far away from keyboards in August and, as a consequence,... be back in 3.10.7 times.

As a heads up (not sure if you follow stable ML), the patches are now under review and test answers are expected by Friday; so, I expect this release to land around Saturday.

aCOSwt wrote:

Because there are users of the ck-sources package who believe in the virtues of rolling releases, who are eager to test new versions, and that is also nice, I just feel I could not abandon them without biscuits until 3.10.7 is out, could I?

Sometimes you have to, you could look for someone to take care of it for you; if you can find someone...

aCOSwt wrote:

Hmmm... This can also make so a 3.9.7 shows regressions toward a 3.9.2...
This probably "because this time we'll do it right".

But that's a lot less likely than the way 3.9.2 shows regressions over 3.8.13; the amount of patches on 5 releases is rather minimal, if you calculate the percentage a patch is a regression you'll find maybe one, two, three or four commits or so; most of which only affect some users. Compare that to all the new functionality, rewrites and so on that comes with a 3.9; a lot of regressions are to be find therein, which is what the patches end up dealing with. So, a kernel that really gets things right might be 3.4.54; but then again, perhaps it contains some regressions that only new functionality or a rewrite could solve...

Picking the right kernel version to push / stabilize / run, it's a whole fun debate on its own; there's some agreement and disagreement, I think there are certainly people that would advocate the opposite...

Because there are users of the ck-sources package who believe in the virtues of rolling releases, who are eager to test new versions, and that is also nice, I just feel I could not abandon them without biscuits until 3.10.7 is out, could I?

Sometimes you have to, you could look for someone to take care of it for you; if you can find someone...

The fact here is that 3.10-ck will... whisper it not... need a local patch.
Of course I know half a dozen of guys capable of taking care of the package for me, but...
Hmmm... how could I say... :
No one of them feel capable of the actually considerable amount of energy usually needed to make a patch find its way to the files directory... _________________