login
Search
Paul Jackson from SGI recently posted a patch to the Linux kernel mailing list explaining, "It's needed to build NR_CPUS > 256."
SGI has already delivered a custom Altix single system image supercomputer to NASA Ames Research Center with 256 processors running Linux, and their 64 processor Linux systems are generally available.
This latest patch seems to indicate that SGI is testing or getting ready to test Linux 2.6 on a machine with more than 256 processors. This would be a great testament to the scalability of the new kernel.
Andrew Morton [interview] released 2.6.0-test9-mm2 noting, "Various random fixes. Maybe about half of these are 2.6.0-worthy." Regarding recently reported issues with I/O [story], Andrew noted that -mm2 includes "some improvements to the anticipatory IO scheduler and more readahead tweaks should help some of those database benchmarks." He concludes, "The anticipatory scheduler is still a bit behind the deadline scheduler in these random seeky loads - it most likely always will be."
Also included in this release is forcedeth, "A new driver for the ethernet interface of the NVIDIA nForce chipset, licensed under GPL." Find more information about Andrew's -mm tree here. Read on for the full changelog of -test9-mm2.
Dave Jones [interview] has posted an updated version of his quite interesting "post-halloween document", otherwise known as "2.6, what to expect". He says, " I couldn't resist the irony of posting a post-halloween document just before halloween. Quite a few changes since last posting here, and with each posting I tend to get a lot of useful feedback for the next round of changes." Dave acknowledges that the document tends to be somewhat x86-centric, "but most features documented here affect all platforms anyway." For those unfamiliar with the post-halloween document, it describes itself as:
"This document explains some of the new functionality to be found in the 2.6 Linux kernel, some pitfalls you may encounter, and also points out some new features which could really use testing."
Read on for the full text of v0.46.
High-end server owners will be especially interested in Martin J. Bligh's -mjb patchset against the 2.6.0 kernel. Martin says:
"The patchset contains mainly scalability and NUMA stuff, and anything else that stops things from irritating me. It's meant to be pretty stable, not so much a testing ground for new stuff. I'd be very interested in feedback from anyone willing to test on any platform, however large or small."
Read on for the full changelog.
Update (Oct 31, 2003): Martin has release -test9-mjb1 [story].
Nick Piggin [interview] released v17a of his scheduler changes saying, "More balancing fixes. I also incorporated some of Andrew Theurer's ideas. I'm generally getting good numbers now, but using fairly synthetic benchmarks."
2.4 stable kernel maintainer Marcelo Tosatti released 2.4.23-pre9 with the following comments:
"Here goes -pre9. Only bugfixes will be accepted till 2.4.24-pre now.
-pre9 backouts out a few ACPI problematic changes. It also includes a USB
update, JFS update, sis900/starfire/tg3 bugfixes, etc.Detailed changelog below.
Please help with testing!"
Read on for the complete changelog.
Marcelo Tosatti released 2.4.23-pre9 noting that he's only accepting bugfixes now, moving toward the 2.4.23-rc stage. He describes the latest changes, "pre9 backouts out a few ACPI problematic changes. It also includes a USB update, JFS update, sis900/starfire/tg3 bugfixes, etc."
Read on for the full changelog.
2.6 kernel maintainer Andrew Morton [interview] released 2.6.0-test9-mm1. He notes the following changes:
A couple of fixes for VM memory reclaim. Finalized the ia32 EFI code. Potentially fixed the IO scheduler regressions. Dropped the runtime-selectable-IO-scheduler patches. Several fixes to the pagecache readahead code, improving performance under "seeky workloads" such as non-direct-io databases.
Read on for the full changelog.
I'm giving 2.6.0-test9 a go, but I'm having some trouble with my IDE (ATAPI) CD-R drive. I can't get it to read without error, and I can't get it to write without error.
This is on x86 with a 2.6.0-test9 vanilla kernel. Using DMA doesn't seem to effect it. The drive fails to read with or without it.
Has anyone else had luck with the ide-cd driver and the ATAPI interface? Is this a known issue? Does anyone have any suggestions to get this working?
After I write hello.c, how(or what) should I do to write the makefile ?
Hello everybody.
After patching 2.6.0-test7 by test8 patch i have error message during compile
Starting an interesting thread about the should and must fix lists recently merged into Andrew Morton's -mm tree [story], Nick Piggin [interview] gathered comments and updated the lists, saying:
"OK, I have incorporated comments. If everyone could try to keep your entries on the list up to date it would be nice. It might give you a bit more bargaining power to get things in."
He goes on to point out that the lists may not be realistic, that 2.6.0 will likely be released prior to the lists being cleared. Nick also highlights a comment made by Alan Cox [interview] who said, "Someone also needs to go fix all the 2.4 security holes still in 2.6 last time I checked - things like the execve holes and execve versus proc races." Read on to see the latest must-fix and should-fix lists.
Bernhard Rosenkraenzer has released 2.4.23-pre8-pac1.
The full changelog follows.
Mike Benoit recently posted a link to results from his new and improved file system shootout, using better hardware and running more tests. Using two benchmarks that are designed to measure hard drive and file system performance, Bonnie++ and IOZone, he's compared a number journaling filesystems found in the 2.6 kernel [forum]. Included in the lineup are EXT2 (not journaling, but an effective baseline [story]), JFS, XFS, ReiserFS, Reiser4, and EXT3 each compared head to head on both SCSI and IDE drives.
In Mike's summary he labels JFS and XFS as 'best bang for your buck' explaining, "While not the fastest file systems, both of them consistently perform close to EXT2, while using minimal CPU. XFS seems to be faster over a wider range of benchmarks, however it does use slightly more CPU than JFS. While JFS really starts to slow down with lots of files." As for pure speed, Mike points to Reiser4 which really shined in the Bonnie++ benchmarks, though not quite so much in the IOZone benchmarks. He suggests, "ReiserFS v4 will [definitely] be worth while keeping an eye on, especially considering some of the exciting new features it offers."
