Linux creator Linus Torvalds announced the first release candidate for the upcoming 2.6.18 kernel, "the merge window for 2.6.18 is closed, and -rc1 is out there". He noted that the changes are extensive, "the changes are too big for the mailing list, even just the shortlog. As usual, lots of stuff happened. Most architectures got updated, ACPI updates, networking, SCSI and sound, IDE, infiniband, input, DVB etc etc etc." Find the shortlog here. Linus went on described additional changes:
"There's also a fair amount of basic infrastructure updates here, with things like the generic IRQ layer, the lockdep (oh, and priority-inheritance mutex support) stuff by Ingo &co, some generic timekeeping infrastructure ('clocksource') stuff, memory hotplug (and page migration) support, etc etc."
From: Linus Torvalds [email blocked]
To: Linux Kernel Mailing List [email blocked]
Subject: Linux v2.6.18-rc1
Date: Wed, 5 Jul 2006 21:26:35 -0700 (PDT)
Ok,
the merge window for 2.6.18 is closed, and -rc1 is out there (git trees
updated, the tar-ball and patches are still uploading over my pitiful DSL
line - and as usual it may take a short while before mirroring takes
place and distributes things across the globe).
The changes are too big for the mailing list, even just the shortlog. As
usual, lots of stuff happened. Most architectures got updated, ACPI
updates, networking, SCSI and sound, IDE, infiniband, input, DVB etc etc
etc.
There's also a fair amount of basic infrastructure updates here, with
things like the generic IRQ layer, the lockdep (oh, and priority-
inheritance mutex support) stuff by Ingo &co, some generic
timekeeping infrastructure ("clocksource") stuff, memory hotplug
(and page migration) support, etc etc.
Git users should generally just select the part they are interested in,
and do something like
git log v2.6.17.. -- drivers/usb/ | git shortlog | less -S
to get a better and more focused view of what has changed.
Have fun,
Linus
From: Matt Keenan <matt.keenan@btinternet.com>
Subject: Re: Linux v2.6.18-rc1
Date: Thu, 06 Jul 2006 10:44:52 +0100
Linus Torvalds wrote:
[snip snip]
> The changes are too big for the mailing list, even just the shortlog. As
> usual, lots of stuff happened. Most architectures got updated, ACPI
> updates, networking, SCSI and sound, IDE, infiniband, input, DVB etc etc
> etc.
>
>
[snip snip]
> Git users should generally just select the part they are interested in,
> and do something like
>
> git log v2.6.17.. -- drivers/usb/ | git shortlog | less -S
>
> to get a better and more focused view of what has changed.
>
[snip snip]
Is it possible to get a URL to a shortlog on a web git somewhere? Has
this information been posted before and I have missed it?
Matt
From: [email blocked] (Jonathan Corbet)
Subject: Re: Linux v2.6.18-rc1
Date: Thu, 06 Jul 2006 06:49:29 -0600
> Is it possible to get a URL to a shortlog on a web git somewhere? Has this
> information been posted before and I have missed it?
Dunno if there's a web git version anywhere, but I did put a copy of the
shortlog with the LWN announcement: http://lwn.net/Articles/190301/
jon
| Problem booting a barebone kernel in VMWare | 2 hours ago | Linux kernel |
| IP layer send packet | 6 hours ago | Linux kernel |
| PID to ELF image full path | 9 hours ago | Linux kernel |
| SMDK2410 LCD Framebuffer driver | 12 hours ago | Linux kernel |
| types of kernel | 23 hours ago | Linux kernel |
| magical mounts | 2 days ago | Linux kernel |
| Problem in scim in Fedora 9 | 2 days ago | Linux general |
| The new Western Digital power saving drives | 2 days ago | Hardware |
| Battery Maximizer Software | 3 days ago | Linux kernel |
| windows folder creation surprise | 3 days ago | Windows |
A lot of changes, but Reiser4
A lot of changes, but Reiser4 is still not one them.
...one of them. Sorry.
...one of them.
Sorry.
There are two things that will never be a part of the kernel...
...closed src binary drivers sponsored by MS and reiser4 :)
There were problems with reiser4 on x86_64 platforms... Are there still problems with these platforms?
No problems so far
>There were problems with reiser4 on x86_64 platforms...
Not that I know of. I've been using reiser4 for some partitions with unimportant/transient data (/usr/portage, /tmp, /var/tmp, /usr/src) since 2.6.14 on amd64 and haven't had any problems yet.
Reiser4 not conforming to CodingStyle
The reason Reiser4 is not in the Linux kernel is not because of the bugs in the drivers, but becasue the driver sources do not conform to Linux source code standards.
Will merge my non-home partition to reiser4
Well, I running Ubuntu dapper with the .18-rc1 kernel and the improvements regarding ACPI are really great! My Turion CPU produces much lesser heat. :)
I've hoped to try out reiser4 in the new release but Linus don't wanted to give me the pleasure, so I will wait for the the next patch available for .18-x kernels and merge at least my non-home partition to reiser4 first.
The benchmark shows really great results und also the user feedback isn't bad. Ok, reiser4 consumes more CPU time but hey(!), who cares if you have a Turion CPU, that idles 98% of the time in 800mhz mode! :)
If you're brave enough to run
If you're brave enough to run .18-rc1, you should be brave enough to run one of the MM kernels, which do come with Reiser4.
Have tried several times...
...to apply the mm-patch of also previous versions (which works). But the patched kernel could be never compiled on my machine (gcc 4.0.3).
Reiser4 is not faster. The reproducable benchmarks prove that.
Take a look at this comment and the reply to in on osnews.
http://osnews.com/permalink.php?news_id=15129&comment_id=141566
In a nutshell, Reiser4 really sucks in the benchmarks and that is reproducable. Also, Hans Reiser ommitted several tests on the reiser4 website benchmarks diagram showing where reiser4 is *signifigantly* slower.
Many users are seeing the filesystem hang as stop as 90 seconds!
Versus ext3 in the 2.6.17 kernel with new performance tweaks, reiser4 doesn't even really compare aside from the fact is has better metadata and is slower.
1. Yes, but Reiser4 uses fas
1.
Yes, but Reiser4 uses fast block-only journal while ext3 uses meta-journal (block journal in ext3 is optional and slow). Turn on block journal (= R E A L journal) and make some tests.
2.
"
REISERFSv4: reiser4progs-1.0.5/sbin/
(Used patch reiser4-for-2.6.14-1.patch w/ libaal-1.0.5 + reiser4progs-1.0.5)"
Quite old-11/11/2005 . ftp://ftp.namesys.com/pub/reiser4-for-2.6/README
3.
- Reiser4 is not fastest... YET - needs only a clean up!
- fast block-journal (first implementation in the world)
- plugin system
- allocate-on-flush & extents (like xfs but not experimental!)
- compression plug in being tested now can overcome typical block alignment style space lost. Plug can even save 50% of space without speed lost
- MS is scared of it
Reiser4 user
Erm.. #1 isn't as bad as you state.
By default, ext3 uses "ordered" mode which pushes out data updates ahead of journalling metadata. Thus, after a crash, you might have a mixture of old and new data in your file without the metadata to reflect it. There's a separate mode, "writeback", that just completely decouples the journal from the data.
From your description, it sounds like ext3 does "writeback" by default, when it actually does "ordered."
FWIW, according to the NameSys website: "V3 of reiserfs offers both meta-data and data journaling, and defaults to meta-data journaling because that is the right solution for most users." So at least as of Reiser 3, ReiserFS offered about the same guarantees as ext3. I realize you're talking about Reiser 4, which does something different.
I personally don't understand the hype around any filesystem. Most of the time, I simply don't even notice the filesystem, and I'm quite happy about that.
Uh, the "hype" is exactly abo
Uh, the "hype" is exactly about how the filesystem behaves in the times that are not "most of the time".
ext3 uses metadata journal as
ext3 uses metadata journal as default. Block journal (this may be the "writeback" option, I do not remember how ext3 calls it) is optional and slow (writes all data twice)
reiserfs uses metadata journal as default. Block journal ("data=journal") is optional and slow (writes all data twice)
jfs uses metadata journal as default. Block journal is not available
xfs uses metadata journal as default. Block journal is not available
reiser4 uses block journal (wandering log) as default, because it writes data once. Because of that meta journal is not available (obsolete).
Typical block journal is slow. Meta journal was introduced to increase speed at cost of decreasing security. The point is to make it as fast as you can without decreasing security too much.
All (except Reiser4) Linux file systems are using some own version of
meta journal. Hans Reiser says that NTFS is one of the poorest meta journal ever made (dangerous and slow), but agrees that XFS's meta journal is better then Reiserfs (Reiser3) - more secure and about the same speed (perhaps even a bit faster). Ext3 has flexible meta journal. O.k. but it is still meta journal! To make ext3 as secure as Reiser4 you need to turn on block-journal (read the beginning) which in ext3 is very slow (much slower then Reiser4). Today Reiser4 is still a bit slower than statistical meta journal fs, but Reiser4 needs only a clean up and bug fix to get it as fast as meta journal, because it already writes data once. Ext3 is at peak of performance while Reiser4 is just starting.
Administrators of big data bases are waiting for fast block journal because of security and speed.
I have few computers. Most of them have small (<7GB) and very small (<500MB) disks . For me Reiserfs (Reiser3) is best as it saves space (specially with small files) and has small structure. No benchmarks just formated 127MB disk in ext3 and reiserfs and put Slackware (most "a" and some "ap"/"n" packages) on it. I am waiting for space saving plug for Reiser4 to move all small disks to it (guess why).
FS is important.
ups
I have few computers. Most of them are small (less then 7GB) and very small (less then 500MB) disks . For me Reiserfs (Reiser3) is best as it saves space (specially with small files) and has small structure. No benchmarks just formated 127MB disk in ext3 and reiserfs and put Slackware (most "a" and some "ap"/"n" packages) on it. I am waiting for space saving plug for Reiser4 to move all small disks to it (guess why).
Kamil
ext3 as THREE modes
ext3 has three modes: writeback (journal metadata only, let data go as it may), ordered (journal metadata only, but push data to disk ahead of metadata), and full data+metadata journaling.
The default for ext3 is "ordered", not "writeback." It's not clear to me whether the other metadata-only journals are closer to "ordered" or "writeback."
Summarizing
O.K. So:
Ext3 uses in default some (in general meaning) version of meta journal (with some extensions or without, cute or not, powerful or not, but still some variation of meta journal, whatever it is called). Right?
On the other hand Reiser4 uses in default some version of block journal and Reiser4 can not use meta journal.
Yes.
Pretty much, yeah. I just wanted to point out that data=ordered does offer somewhat stronger guarantees than data=writeback. A good number of the criticisms aimed at ext3 are valid only for data=writeback.
Reiser4, because it uses a structure that sounds similar to the "phase tree" stuff that Tux2 was looking at awhile back. Since you don't double-copy, you only have to work with the metadata, which Reiser4 stores in a tree structure, IIRC.
Reiser4 structure is "dancing
Reiser4 structure is "dancing trees", but I do not know how exactly does it "work". Reiser4's block journal works like that http://en.wikipedia.org/wiki/Wandering_log
reiser4
Where is reiser4 ??!!
Some distributions are alread
Some distributions are already using it even as default (like Yoper). If you are not lucky go to home page www.namesys.com. The installation info is be a bit outdated (says that 2.6.11-5 is the newest kernel), but the procedure did not change.
Patches:
ftp://ftp.namesys.com/pub/reiser4-for-2.6
(note: Reiser4 is also available in "-mm" patches)
Tools:
ftp://ftp.namesys.com/pub/reiser4progs
Swap Prefetch?
No swap prefetch?
Looks like the desktop gets the back seat forever with linux now...
Only in the mainline kernel
Nothing stops a desktop oriented distro from patching this into their kernel. That's the beauty of open source. If someone wants to put Reiser4, swap prefetch, and a different scheduling algorithm in their "desktop tuned" distribution, nothing stops them.
The fact that many of these pieces live in the -mm kernel (at least last I knew--I don't follow -mm that closely) means that they stay relatively up to date, too.
Huh?
Desktop has nothing to do with it. Any feature must have its pros
and cons weighed up.
swap prefetching is a change to the core memory management, and it
has not really had much numbers to back it up yet. Aside from
several people saying "its faster for me for xxx".
If it is faster, it will be easy for someone to get numbers that
can be verified and at that point a decision might be made as to
whether or not it is worthwhile.
Unless... have you already reviewed it thoroughly yourself, then
posted numbers showing significant improvements?
Comes with the patch
It speeds up firefox startup after a complete swapout by 5 times. Other apps show similar speedups.
Maintaining swap prefetch
I used to track -ck until git came about. My favourite features were
isosynchronous scheduling:
This was the only way I could maintain a full quality VoIP session whilst compiling, running svn update or even when browsing Web pages with lots of JavaScript!
swap prefetching:
It _seemed_ to help make programs launch faster, unlike other patches that were in ck from which I didn't notice a real benefit (not to say that they didn't help). Of course, I can't say if this was at the expense of other operations, but I didn't notice slowdowns anywhere else.
But since git has come around, tracking git-maintained branches has given me a much faster way of working at the expense of not being able to track non-git patchsets as easily. I no longer use ck and I do miss it, but not enough to apply the patches by hand.
Maybe if you (or a volunteer) were to maintain a git branch with the best of -ck, it would help old -ck enthusiasts track ck again. With more users giving positive feedback, and an easy way for mm and Linus to git pull the changes, there could once again be a clear path towards mainline?
git-pulling gives maintainers a buzz, and this probably applies doubly to Linus, who is git fan No. 1. In a perfect world, you would just have to submit the patch, but since there do appear to be politics, maybe a git-maintained -ck is what's called for?
Requested
I've had it requested many times before, but running git is unnecessary rocket science to do basic patching which is all -ck is.
mm as the new unstable
Have the interesting patches mentioned above made it to -mm yet?
Why/why not?
swap prefetch has made it to
swap prefetch has made it to MM, but andrew morton is not convinced it helps, so it didn't end up in 18rc1.
the other patches are only in -ck, tough sometimes some things end up (in one or another way) in the kernel. in the case of staircase, it won't get into the kernel (tough it is smaller, cleaner, and performs slightly better) because the cpu scheduler maintainer thinks ppl should stop 'wasting' time on an alternative design but instead work on his scheduler and improve it. So he and others add hack onto hack to keep it working.
Hmmm... how do you measure swap prefetch?
Swap prefetch won't help most benchmarks. It's meant to help the "drowsy computer after updatedb runs in the middle of the night" syndrome more than it is to help typical benchmarks.
Really, you want to benchmark it to ensure it doesn't change normal VM performance noticeably. If it doesn't affect normal VM performance, but it reduces latency after a large thrashout load (a difficult but not impossible thing to benchmark), then why wouldn't you include it?
I guess you could do a synthetic benchmark:
1. Task A allocates and dirties a bunch of memory, and then sleeps.
2. Task B allocates more than system RAM, dirties and reads it, thus forcing Task A to swap.
3. Task A continues to sleep, long enough that swap prefetch should do something.
4. Task A semi-randomly reads all its allocated pages, timing how long that takes.
That would at least verify that swap prefetch brings Task A back in from swap without Task A faulting itself in. I can imagine folks shaking their head at how hokey the benchmark feels though.
common case?
Complete swapout of firefox isn't that common though. I have
only 256MB RAM on my daily use system, and mozilla browser
doesn't swap out very much even after doing editing/compiling
and leaving it to run updatedb overnight.
It is in some places
My Linux workstation at work runs lots of big batch jobs while I'm home sleeping. I come in, and for the first hour, Firefox is worthless. I wouldn't mind shortening that down to the first 12 minutes. (And something tells me if this patch does its thing, it'll be faster than that.)
Firefox
That says more about Firefox than anything else really... :/
Well, not just Firefox
Sure, Firefox has a huge footprint, but I do usually have about 3 windows with a dozen tabs each open in them. Even Xscreensaver (for which the only screen saver I have enabled is "blank") takes several seconds to come out of swap.
*Everything* is pushed to swap.
When will ACX1xx driver be in kernel?
I have been using this driver for a long time...
See the article Reverse Engin
See the article Reverse Engineering Wireless Drivers.
kernel 2.6.18-rc1-git4
After having some serious trouble with the stable versions of kernel 2.6.16 I am very happy with kernel 2.6.18. I run my laptop with rc1-git4 since several days and had absolutely no problems yet.
Great work!