Ubuntu 9.10 Off To A Great Performance Start

[KDesk]

Ehm, same 'regression' on Linux, *BSD and Solaris?

I still hope we'll see Ubuntu x86_64 on Ext 4 partition vs Macos comparison.

+1 (also with some tweaks)

[MaestroMaus]

and while it does NOT yet

Typo on the first sentence.

[hdas]

I am guessing it might be a Core-i7 thing - may be new kernel and gcc are more optimized for it. Would be very surprised if that's the case for E8400 too, since the Core2 architecture has been around for quite a while. Pretty happy anyways .

[Luis]

Ok, so since everyone is trying to guess here, I'll try my guess too:

Could the performance improvements (they are most notable in I/O operations) be due to changing the default in ext3 from date=ordered to data=writeback? In other words, anyone could have enjoyed these improvements years ago, as long as they don't care about a few safety/security problems when mounting the filesystem with data=writeback.

Well, at least one of those safety problems have been addressed so you won't get zeroed files if a crash happens just after a file is renamed/replaced by a program that does not use sync. Still, you might get files from other users (or other users can get files belonging to you).

[deanjo]

Ok, so since everyone is trying to guess here, I'll try my guess too:

Could the performance improvements (they are most notable in I/O operations) be due to changing the default in ext3 from date=ordered to data=writeback? In other words, anyone could have enjoyed these improvements years ago, as long as they don't care about a few safety/security problems when mounting the filesystem with data=writeback.

Well, at least one of those safety problems have been addressed so you won't get zeroed files if a crash happens just after a file is renamed/replaced by a program that does not use sync. Still, you might get files from other users (or other users can get files belonging to you).

Not sure but the regression happened around the 2.6.18 time frame. It's just now that Ext3 finally starts performing like it did back then.

[susikala]

Ok, so since everyone is trying to guess here, I'll try my guess too:

Could the performance improvements (they are most notable in I/O operations) be due to changing the default in ext3 from date=ordered to data=writeback? In other words, anyone could have enjoyed these improvements years ago, as long as they don't care about a few safety/security problems when mounting the filesystem with data=writeback.

Well, at least one of those safety problems have been addressed so you won't get zeroed files if a crash happens just after a file is renamed/replaced by a program that does not use sync. Still, you might get files from other users (or other users can get files belonging to you).

Correct me if I'm wrong, but data=writeback is in the default kernel. The one used in the benchmarks however is rebranded, are you sure Ubuntu doesn't fall back to data=ordered, like predicted by Corbet at least for some time?

[jbrown96]

I have to give Michel a lot of credit for this article. It's significantly better than the last article about Ubuntu 9.10 (the Intel graphics regressions) that I complained about so loudly. There's some good discussions about why performance improved. I particularly like the discussion about the MySQL test. This is a great step forward. Keep it coming Michel, and of course, the entire Ubuntu team.

[drag]

Great to see the Kernel devs making an effort to improve the desktop experience ... makes me tempted to upgrade to the 2.6.30 kernel on Jaunty (not sure if thats possible)

It should be.

Use the kernel-package program.

What you do is basically this:
1. download the source code from kernel.org. Untar it to /usr/src

2. in the linux-2.6.30 directory, copy your /boot/config-2.6.29-whatever to /usr/src/linux-2.6.30/.config

3. Run 'make oldconfig'

Answer any questions that pop up. If it asks questions it is because of features in 2.6.30 that are not in 2.6.28-whatever-the-hell-it-is. If you don't know the correct answer, choose the default as it's the safest setting.

What this does is that you get as close as possible to original kernel's configuration.

Then run the make-kpkg stuff.


Something like this:

make-kpkg clean
make-kpkg --config=menuconfig kernel_image modules_image

What this does is that it compiles the kernel and packages it into debian packages. Then you just install the .deb package.

What this does is that it allows you to remove your current kernel (which I don't recommend) it fullfills any package dependences and it'll run all the hooks to configure grub and all that when you install it.

Also it makes it easy to uninstall it.

That is about the safest way to build a custom kernel. Just remember if it doesn't work then you can go back to the original one.

good luck.

[neuron]

Worth mentioning that new kernels default to ext3 in writeback mode rather than ordered, I'm guessing that's where all your disk improvements come from.

[Kano]

@drag

When you use root=UUID=... then you should compile kernels with initrd support (--initrd option). Also intersting is to compile a kernel from Ubuntu git, when you add a git pull master you can update em to latest code. Currently merging is a bit tricky, but not impossible. I packaged -5 kernels updated to rc6 for Kanotix. There you see the changes in U git:

http://kernel.ubuntu.com/git?p=ubunt....git;a=summary

Needed packages:

sudo apt-get install git-core kernel-package kernel-wedge debhelper build-essential devscripts makedumpfile fakeroot

To checkout:

git clone git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git

To update:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git master

edit the files which fail to merge (seek for <<<< and >>>>), most of the times it is straight forward. Then

git add file-1-edited file-2-edited

git commit

to compile the generic kernel:

time fakeroot debian/rules binary-debs flavours=generic skipabi=true skipmodule=true

missing package for header:

time fakeroot debian/rules binary-headers