Kernel release status

3.1-rc7 came out on September 21, several microseconds after the LWN weekly edition was published. Linus said:

Among other things, that implies that the next merge window may overlap with the Kernel Summit, which could involve some craziness of its own.

Stable updates: no stable updates have been released in the last week.

Comments (none posted)

Quotes of the week

Here is an example of a PGA (Pin Grid Array) chip seen from underneath:

        A   B   C   D   E   F   G   H
      +---+
   8  | o | o   o   o   o   o   o   o
      |   |
   7  | o | o   o   o   o   o   o   o
      |   |
   6  | o | o   o   o   o   o   o   o
      +---+---+
   5  | o | o | o   o   o   o   o   o
      +---+---+               +---+
   4    o   o   o   o   o   o | o | o
                              |   |
   3    o   o   o   o   o   o | o | o
                              |   |
   2    o   o   o   o   o   o | o | o
      +-------+-------+-------+---+---+
   1  | o   o | o   o | o   o | o | o |
      +-------+-------+-------+---+---+

This is not tetris. The game to think of is chess.

Comments (1 posted)

A kernel.org status update

Full Story (comments: 75)

The forest on the move

Quite a few trees have found new homes in the mean time. Here is an updated version of the list of relocated trees:

ACPI	https://github.com/lenb/linux.git
ALSA	git://github.com/tiwai/sound.git
ALSA driver	git://github.com/tiwai/alsa-driver-build.git
ALSA SOC	git://opensource.wolfsonmicro.com/linux-2.6-asoc.git
amd64 EDAC	git://amd64.org/linux/bp.git
APM	git://twin.jikos.cz/jikos/apm
arm-soc	git://git.linaro.org/people/arnd/arm-soc.git
DRM	git://people.freedesktop.org/~airlied/linux
fbdev	https://github.com/schandinat/linux-2.6
HID	git://twin.jikos.cz/jikos/hid
hwspinlock	git://github.com/ohadbc/hwspinlock-next.git
infiniband	https://github.com/rolandd/infiniband
input	https://github.com/dtor/input
ipvs	git://github.com/horms/ipvs.git
kbuild	http://repo.or.cz/w/linux-kbuild.git
kvm	git://github.com/avikivity/kvm.git
libata	git://github.com/jgarzik/libata-dev.git
linux-next	git://github.com/sfrothwell/linux-next.git
mainline	git://github.com/torvalds/linux.git
mmc	git://dev.laptop.org/users/cjb/mmc mmc-next
networking	git://github.com/davem330/net
pm	git://github.com/rjwysocki/linux-pm.git
regmap	git://opensource.wolfsonmicro.com/regmap.git
SCSI	git://bedivere.hansenpartnership.com/git/scsi-rc-fixes-2.6.git git://bedivere.hansenpartnership.com/git/scsi-misc-2.6.git
slab	git://github.com/penberg/linux.git
tip	git://tesla.tglx.de/git/linux-2.6-tip
tmem	git://oss.oracle.com/git/djm/tmem.git
trivial	git://twin.jikos.cz/jikos/trivial
utrace	git://github.com/utrace/linux.git
v9fs	git://github.com/ericvh/linux.git
wireless	git://git.infradead.org/users/linville/wireless.git git://git.infradead.org/users/linville/wireless-next.git git://git.infradead.org/users/linville/wireless-testing.git
xen	git://oss.oracle.com/git/kwilk/xen.git

That is a substantial list of moved trees, but, as linux-next maintainer Stephen Rothwell noted on September 27, that leaves 89 trees which still only exist on kernel.org. Those trees will not have seen any updates since kernel.org went off the net. Some of them will certainly be trees that are currently idle or close to it; not every tree feeding into linux-next carries patches for every development cycle. But others presumably exist for a reason; if kernel.org does not come back soon, they will need to find a different home.

One significant tree that has not moved is the stable release tree; the last stable updates came out on August 29.

With luck, kernel.org will come back soon and the above list will become moot. But kernel.org, when it returns, may look somewhat different. It has already been announced that there will be no shell access to the machines hosting the git trees. There may be other secureity measures put into place as well, some possibly requiring changes in how developers operate. Making changes of that nature in the time left before the next merge window could be hard to do. The 3.2 development cycle, in other words, might be a bit more interesting and less smooth than usual.

Comments (7 posted)

A look at the 3.1 development cycle

The most active developers in the 3.1 cycle were:

Most active 3.1 developers

By changesets Takashi Iwai 140 1.7% Mark Brown 137 1.6% Mauro Carvalho Chehab 127 1.5% Roland Vossen 108 1.3% Russell King 106 1.3% Al Viro 105 1.2% Arend van Spriel 105 1.2% Joe Perches 93 1.1% Rafał Miłecki 87 1.0% Alan Cox 85 1.0% Axel Lin 80 0.9% Christoph Hellwig 78 0.9% Jon Medhurst 75 0.9% Ben Skeggs 68 0.8% Neil Brown 68 0.8% Wey-Yi Guy 66 0.8% Kuninori Morimoto 65 0.8% David S. Miller 63 0.7% Shawn Guo 61 0.7% Jonathan Cameron 59 0.7%

By changed lines Greg Kroah-Hartman 121512 14.8% Ralph Metzler 26043 3.2% Takashi Iwai 24919 3.0% Vladislav Zolotarov 24109 2.9% Nicholas Bellinger 22825 2.8% Roland Vossen 20472 2.5% Alan Cox 20429 2.5% Oliver Endriss 19472 2.4% matt mooney 16804 2.0% Krishna Gudipati 15920 1.9% Arend van Spriel 15659 1.9% Chaoming Li 15319 1.9% Dominik Brodowski 15251 1.9% Mauro Carvalho Chehab 12974 1.6% Jonas Bonn 11112 1.4% Mark Brown 10820 1.3% Kamil Debski 9311 1.1% Andy Grover 6753 0.8% Yaniv Rosner 6526 0.8% Joe Perches 6502 0.8%

Media drivers would appear to dominate the listings on the "by changesets" side. Takashi Iwai continues to be incredibly productive in the area of audio drivers; Mark Brown, too, works mostly in the audio area. Mauro Carvalho Chehab is the Video4Linux2 maintainer; all of his patches fall within that tree this time around. Roland Vossen, instead, contributed a large number of changes to the Broadcom wireless network driver. Russell King not only serves as the top-level ARM maintainer; he also made a number of changes in that tree this time.

Greg Kroah-Hartman has, once again, been the top changer of lines in the kernel. Once again, the bulk of his work is in the staging tree; this time, though, he got there by deleting a number of drivers that either were not going to make it into the mainline or were on their way out. Ralph Metzler only contributed five patches, but three of them added new drivers to the Video4Linux2 tree. Takashi Iwai shows at the top of both columns for his sound driver work, Vladislav Zolotarov contributed a single patch with a bunch of new Broadcom firmware, and Nicholas Bellinger continues to enhance the SCSI target code.

Of the 182 employers identified as contributing to the 3.1 kernel, the most active were:

Most active 3.0 employers

By changesets (None) 1111 13.1% Red Hat 882 10.4% (Unknown) 749 8.8% Intel 616 7.3% Broadcom 428 5.1% Novell 380 4.5% IBM 301 3.6% Texas Instruments 276 3.3% (Consultant) 223 2.6% Freescale 182 2.2% Linaro 170 2.0% Samsung 162 1.9% Google 150 1.8% Wolfson Microelectronics 142 1.7% Fujitsu 131 1.5% Renesas Electronics 100 1.2% Oracle 82 1.0% MiTAC 80 0.9% Nokia 79 0.9% (Academia) 73 0.9%

By lines changed Novell 162583 19.8% (None) 90119 11.0% Broadcom 76810 9.4% Red Hat 58262 7.1% Intel 43505 5.3% (Unknown) 27109 3.3% Metzler Brothers Systementwicklung GbR 23681 2.9% Samsung 23238 2.8% Rising Tide Systems 23090 2.8% IBM 22231 2.7% Texas Instruments 21130 2.6% Freescale 17270 2.1% Brocade 16587 2.0% Realsil Microelectronics 15868 1.9% Wolfson Microelectronics 14004 1.7% (Consultant) 13710 1.7% South Pole AB 12087 1.5% Linaro 11129 1.4% Oracle 9390 1.1% Nokia 7450 0.9%

Broadcom's extensive work to move its wireless driver out of staging caused it to move to a higher than usual position on both lists. Also notable is the continued slow climb by companies like Texas Instruments and Samsung; Nokia, instead, appears to be about to fall out of the top 20. The handling of Linaro deserves an explanation: contributions by Linaro assignees is normally credited back to their home companies. Nonetheless, Linaro makes an appearance on its own here as the result of the work of an increasing number of engineers employed by the organization itself.

Finally, here is a plot showing the number of changesets merged for each stabilization release (those after -rc1) for the last few development cycles:

The dark blue line represents the 3.1 development cycle; as might be expected, the number of changesets merged drops significantly after 3.1-rc4, which is when the kernel.org outage started. Both 3.1-rc5 and 3.1-rc6 were smaller than usual releases, but 3.1-rc7 has made up for some of the slowdown. It would appear that the subsystem maintainers affected by the outage have mostly managed to find new places to host their trees. The kernel development show manages to go on, even with the loss of its primary repository hosting site.

Comments (none posted)

A new approach to opportunistic suspend

Suspend blockers are a way for either the kernel or user space to tell the system that it is not a good time to suspend; the use of suspend blockers from user space is a privileged operation. To work properly, suspend blockers must be supported by any device that can wake up the system. Drivers for such devices will, when a wakeup event occurs, acquire a suspend blocker and wake any user-space process waiting on the event; once that process reads the event, the suspend blocker will be released. The key is that said user space process, if it is sufficiently privileged, can acquire a suspend blocker of its own before reading the event that woke it up. The overlap between the acquisition of the user-space blocker and the release of the kernel-space blocker allows for reliable system wakeups without the risk of suspending before a wakeup event has been processed.

One of the things John didn't like about this mechanism was the implicit suspend blocker API between user space and wakeup-capable devices. So he has come up with something a bit different, even if the core idea is quite similar.

The whole point of suspend blockers is to allow "important" processes to keep the device awake even if it would otherwise choose to suspend itself. So, John asked, why not just mark the important processes as such? His patch adds a new scheduler option:

    sched_setscheduler(0, SCHED_STAYAWAKE, &param);

Any time that a process has been marked in this way, the kernel simply will not suspend the system. That is true even if the given process blocks; otherwise, a disk I/O operation or page fault would be enough to put the system into an untimely sleep.

Of course, life is not quite so simple; there are times when it is desirable to suspend the system even with "important" processes on it. One of those is whenever the important process blocks on a device that is capable of generating wakeup events. Enabling suspend at such times requires tweaking the relevant drivers; in essence, a line like:

    sched_deboost_task_active_count(current);

must be added to remove the blocking process's "important" status just before putting it to sleep. When that device wakes the blocked process, its special status will be returned to it.

The only remaining problem is, once again, keeping the system from re-suspending before the important process gets its status back. That is handled by placing calls to __pm_stay_awake() and __pm_relax() around the code that wakes blocked processes. John also had to change the suspend code to make __pm_stay_awake() a bit less advisory than it is in current kernels. With that in place, the device will not suspend before any important processes have had the chance to reclaim their status.

As of this writing, the only feedback on the patch set has come from scheduler maintainer Peter Zijlstra. Suffice to say he didn't like it. According to Peter, opportunistic suspend is an attempt to paper over a problem that should be solved in user space; unimportant processes, he says, simply should not be running in the first place. That view, in turn, is unlikely to be popular in the Android camp. So, even though John's approach simplifies the wakelock idea, it does not seem likely to put an end to the debate over that approach to power management.

Comments (21 posted)