ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc6/2.6.12-rc6-mm1/

• Added v9fs
• Various random fixes
• Probably a similar number of breakages

4Kb kernel stacks are the future on i386, and it seems the problems it initially caused are now sorted out.

I'd like to:

• get a patch into the next -mm that unconditionally enables 4KSTACKS
• if there won't be new reports of breakages, send a patch to completely remove !4KSTACKS for 2.6.13 or 2.6.14

The only drawback is that REISER4_FS does still depend on !4KSTACKS. I told Hans back in March that this has to be changed.

Is there any ETA until that all issues with 4Kb kernel stacks in Reiser4 will be resolved?

If not people using Reiser4 might have to decide whether to switch the filesystem or the architecture...

For the past few weeks, we've been conducting comparison tests between PREEMPT_RT and the Adeos nanokernel. As was clear from previous discussion, we've been open to be proven wrong regarding endorsement of either method. Hence, this comparison was done in order to better understand the impact of each method vis-a-vis vanilla Linux.

At this time, we are publishing the summary results of the various test runs we've conducted. There is, of course, a lot of background information that needs to be provided (.configs, scripts, drivers, etc.) We will be making those available sometime early next week. In the mean time, the following is meant as food-for-thought.

In our tests, we've used a set up with 3 machines. The two main systems were Dell PowerEdge SC420 machines with a P4 2.8 (UP not SMP configured) with FC3. One had 256 MB RAM and was the guinea pig (i.e. the machine controlling the mechanical saw a.k.a. TARGET) The other, having 512 MB RAM, was used to collect data regarding the guinea pig's responsiveness (a.k.a LOGGER.) The third machine, an Apple PowerBook 5,6 G4 / 1GB, was used for a dual purpose. First, it controlled both the target and the logger via ssh, and was also used to ping flood the target. This 3rd system is known as the HOST.

Data was generated on all three systems:
TARGET: LMbench data
LOGGER: Interrupt response time
HOST: LMbench total running time

Both the host and the logger had a constant kernel configuration. The logger was running an adeos-enabled kernel in order to trigger and deterministically measure the responsiveness of the target. The host was running a plain gentoo-based kernel. The target and the logger were rigged via their parallel ports so that an output from the logger would trigger an interrupt on the target who's response would itself trigger an interrupt on the logger.

In the various test runs, we've attempted to collect two sets of data. One regarding LMbench's total running time for a given set up and the other regarding the system's interrupt response time. Where appropriate, both tests were conducted simultaneously. Otherwise, they were conducted in isolation. The following tables should be self-explanatory.

For LMbench test runs, 3 passes were conducted and an average running time was collected. Certainly, 3 passes is not as much as we'd like, but for the immediate purposes, it provides a sufficiently corroborated data set for analysis (as can be seen in the following tables.)

For the interrupt response time measurement, the logger generated between 500,000 to 650,000 interrupts and measured the target's response time. The logger was not subject to any load whatsoever, except that imposed by the logging driver (running in a prioritary Adeos domain, and hence being truly hard-rt, a.k.a. "ruby" hard) and that of the user-space daemon committing the data to storage. It could be argued that the use of Adeos imposes a penalty to the measured response time. However, this penalty is imposed on all data sets, and verification of its impact can be inferred by analyzing the adeos-to- adeos set up provided below.

With no further ado, here are the results we've obtained. As we said above, we will be making all related scripts, patches, and drivers available, so that others may conduct their own tests.

Note that in the tests we've conducted, we've tried, in as much possible, to use similar kernels. However, we were unable to find a recent Adeos and a recent PREEMPT_RT patch which would both cleanly apply to a same recent kernel. Hence, we've compared vanilla 2.6.12-rc2 with an adeos-patched one and a 2.6.12-rc4 with a PREEMPT_RT-patched one. As can be seen below, the runs of the vanilla rc2 and rc4 yield very similar numbers, and can therefore reasonably be considered equivalent.

LMbench running times:

Legend:

plain	= Nothing special
IRQ test	= on logger: triggering target every 1ms
ping flood	= on host: "sudo ping -f $TARGET_IP_ADDR"
IRQ & ping	= combination of the previous two
IRQ & hd	= IRQ test with the following being done on the target: "while [ true ]     do dd if=/dev/zero of=/tmp/dummy count=512 done"

In the following, interrupts are triggered by the logger at every 1ms. It would be interesting to redo such tests with shorter trigger times. However, we wanted to keep the logger as "off-the-shelf" as possible.

Interrupt response times (all in micro-seconds):

Legend:

None	= nothing special
ping	= on host: "sudo ping -f $TARGET_IP_ADDR"
lm. + ping	= previous test and "make rerun" in lmbench-2.0.4/src/ on target
lmbench	= "make rerun" in lmbench-2.0.4/src/ on target
lm. + hd	= previous test with the following being done on the target: "while [ true ]     do dd if=/dev/zero of=/tmp/dummy count=512 done"

Note: Adeos-r10c3 is a "combo" patch including both Adeos and PREEMPT_RT, though PREEMPT_RT is disabled.

The above data has been provided as-is without any analysis for now. We will provide such analysis when publishing the complete data sets and related software. In the mean time, we hope such results will help further reflection.

Much to our dislike, we only noticed that we forgot to disable the debug options after posting the results :/ So, in all fairness, we will be redoing the tests on PREEMPT_RT early next week. In the plethora of things we wanted to try, it also seems that the "dd" test wasn't exactly as it was supposed to be. There should've been a "bs=1M" in there; as it currently is, the dd command doesn't really put any real load. We'll add this one to our repeats.

I notice there are already suggestions regarding additional types of tests, and that's good. We'll try to take as many of these as possible. This is relatively simple given the scripts Kristian has put together. Nevertheless, it must be understood that we don't have infinite resources. So in sharing the framework we've developed, we hope others will be motivated to conduct their own tests.

As everyone knows[1], devfs is going to be removed from the kernel soon. To accomplish this, here is a series of patches (22 in all) that do just that. Surprisingly enough, devfs was almost everywhere in the kernel, that's why it takes so many patches :)

Anyway, here's the whole series against 2.6.12-rc6-git4. If some of them don't make it through to lkml (due to size restrictions, or just failing on a "taste" filter), you can find them all at:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/
along with a quilt series file to apply them with.

Andrew, please do not pick these up for your -mm tree. Odds are it will just cause too many conflicts to make it worth your while :)

Comments welcome.

Oh, and the best part? Here's the summary of the diffstat:

222 files changed, 112 insertions(+), 8545 deletions(-)

It's nice to remove code from the kernel for a change...

thanks,

greg k-h

[1] What? You don't know this? Didn't you get the memo[2]? Did you miss the huge flame war almost a year ago[3]? Are you living under a rock[4]?
[2] http://lxr.linux.no/source/Documentation/feature-removal-schedule.txt
[3] http://thread.gmane.org/gmane.linux.kernel/219278
[4] http://www.balloonplanet.com/shop/images/products/product_1788_small.jpg

I'm talking about drivers in the mainline kernel tree.

In some cases the driver author supports both 2.4 and 2.6 and prefers to support them in one file. Sometimes he submits the latest version of his driver to Marcelo or Linus.

If you remove the global function dummies, you force every driver maintainer who works this way to add the function dummies to their drivers.

Yes, there are many places where 2.4 and 2.6 are not source compatible for good reasons. But if the effort for maintaining compatibility between 2.4 and 2.6 in one area is as easy as keeping a header file with some dummy funtions it's worth considering.

And keeping the compatibility stuff in one file instead of spreaded through the kernel sources makes the cleanup to remove the last occurences a few years from now easier.

We (the -stable team) are announcing the release of the 2.6.11.12 kernel.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between 2.6.11.11 and 2.6.11.12, as it is small enough to do so.

The updated 2.6.11.y git tree can be found at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/linux-2.6.11.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/

This set of patches fixes gcc4 problems in the 2.4.31 kernel's 'core' code. I've been running gcc4-compiled 2.4 kernels for several months on i386, x86_64, and ppc32, and there are currently no known regressions compared to gcc34.

Note: you'll want to use recent gcc-4.0.1 snapshots as gcc-4.0.0 is known to be broken.

This set of patches do not include fixes to drivers, file systems, or architectures I don't use myself. I have a preliminary patch kit for those, but as it has received only limited compile testing I'm not submitting it unless these core patches are accepted.

I'm working with the Software Revolution and I thought you guys might like to know that we just completed the automatic generation of a full, design-level documentation of the LINUX kernel and associated sub-systems. This documentation set is made up of hyperlinked graphics and text documents of all the major subsystems and all of the source code fields and functions and is organized by complexity and file-system location. It covers the Linux kernel, memory management, file-system, security, cryptography, initialization, drivers, architecture and interprocess communication subsystems. Furthermore, we're offering this for... well free. I just thought it was something maybe you guys could use. If you would like to view this information, just go to:

http://www.softwarerevolution.com/jeneral/open-source-docs.html