Kernel release status

Posted Sep 1, 2005 15:12 UTC (Thu) by Duncan (guest, #6647) [Link]

There were some changes to suspend in the 13-rcs, allowing successful
suspend to RAM on my dual CPU Opteron for the first time (altho only if I
hadn't run much since boot, after starting X, even if I shutdown X, it
wouldn't work, but still, it was enough to give one hope).

The key there was dual CPU. The patches used the CPU hotplug code to shut
down all but the one CPU (so the second one in my case, but for a quad, it
would of course be three of the four, etc.), then used single-CPU suspend
to shut it down. Yes, it /did/ successfully wake back up, too, at least
some of the time. Because the CPU hotplug code had only been fully merged
with the 13-rcs as well (tho prep patches cleaning up and preparing for
CPU hotplugging have been being merged for some time), it would have been
impossible to do this earlier, at least with vanilla kernel.org official
Linus mainline.

However, Linux made the executive decision that the new suspend code
patches, while improving functionality for many, regressed currently
working functionality for others, and thus, until more of the regressions
are sorted, it was pulled. By 13-rc6, I could no longer suspend, even
after a fresh reboot. I haven't tried on 13 itself, but from what I've
read (I think all here on LWN, but from the rcX changelog notes as posted
by Linus) I don't believe the code was to be returned until at least the
pre-14-rc1 open additions season.

So... they are DEFINITELY actively working on it, both suspend to disk
(which I have NOT tried recently, as I have swap disabled at present, tho
I'm thinking about enabling it again, so I /can/ try suspend to disk) and
suspend to ram. There's some cleanup and prep code in 13, and they DID
try to get some functionality changes in as well, but all of those were
reverted until at least 14, to the best of my knowledge. This current
pre-14-rc1 open patching period was supposed to bring some additional
merging of functionality between the two implementations as well, however,
so it's quite likely 14 will see the changes pulled from 13 and additional
changes as well, hopefully curing the regressions that caused the pull of
the 13 changes, in the process. The code has a good chance of being in
-rc1, certainly, but if the regressions can't be fixed to Linus'
satisfaction in time, then it'll again be pulled and wait for the
pre-15-rc1 open patching period.

That brings up something else of note... At OLS this year, the kernel
crew decided a stricter rc policy was warranted, hopefully leading to
faster kernel version turnaround times. Where they've recently been
running about 90 days between kernel versions, taking more time to
stabilize full releases due to complaints about regressions in earlier 2.6
releases, they are now going to try to shorten the turnaround time,
without shortening the stabilization time, by limiting major changes to
the first couple weeks after a release, the pre-rc1 open patching period I
mentioned above.

rc1, then, will correspond very well to the pre series of
old. rc2 will be the first stabilization patchs, allowing no new features
but still some semi-invasive stabilization changes. If after rc2, serious
regressions remain that can't be fixed with minimally invasive
stabilization patches for rc3, the patch will be reverted to last release
state and will have to wait until the next pre-rc1 open patching period.
Thus, rc3 should be considered the first "proper" rc=release candidate.
There may be an rc4 if necessary, but the goal is to prevent having an rc5
and above by confining the invasive changes sometimes allowed as late as
rc3 lately, to rc1, and pulling the changes until the next open patching
period if they require major or invasive additional patching post rc2.

Thus, this represents a second policy tweak to the post 2.6 kernel policy
of OLS-2004, the first being the reemphasis on having a decently stable
release, first seen with 2.6.11, some months ago. Shorter "open patching
periods", followed by a decent stabilization period, should result in
nearly two releases for every one we've been seeing of late. Less "new"
stuff in each one, but more stabilization than early 2.6 kernel releases,
and shorter release cycles than we've seen for the last couple releases.

What that means for the new suspend features, then, is that those pulled
for 13 should have another try with 14 in 6 weeks to 2 months, rather than
the three months it took between 11 and 12, and between 12 and 13. If
they don't make it there, then there'll be a another chance with 15, which
really shouldn't be much farther out than 14 /would/ have been, given the
recent release timing history. Two chances in 3-4 months, rather than
only one chance, thus dropping the relative costs of not making a release,
a factor that should lead to more stable code even by itself.

Of course, that's the agreed policy in theory. How well Linus actually
sticks to it in practice remains to be seen, but with the formal policy
there, it should make it easier for him to enforce than just the general
feeling that stabilization was suffering earlier, or that releases were
taking too long and thus actually contributing to the stabilization
problems by increasing the cost of missing one, lately.

Hope all of that's helpful to someone...

Duncan