| View previous topic :: View next topic |
| Author |
Message |
kyPixel
Tux's lil' helper
Joined: 31 Jan 2005
Posts: 117
|
 Posted: Mon Jun 06, 2005 8:27 pm Post subject: IS it really worth upgrading to 2.6? |
 |
|
Been wondering if a 2.6 kernel is really that much better, and worth the time to actually update the kernel...
I'm using 2.4.26-gentoo-r9 at the moment, it does what I need, but from what i've read about 2.6 is that it's much fast and gives better hardware support... not that I neeed it at the moment, but I may need to in the future...
Opinions? |
|
| Back to top |
|
 |
ansient
Guru
Joined: 22 Jan 2005
Posts: 445
Location: Argentina
|
| Posted: Mon Jun 06, 2005 8:35 pm Post subject: |
|
|
| Quote: | | Been wondering if a 2.6 kernel is really that much better, and worth the time to actually update the kernel... |
Yes, and yes. |
|
| Back to top |
|
|
kill
Apprentice
Joined: 25 Dec 2004
Posts: 179
|
| Posted: Mon Jun 06, 2005 8:41 pm Post subject: |
|
|
| If it's not broke don't fix it. 2.6 has a much better layout, and better hardware support. As for being faster, that is debatable. If everything you have works fine with 2.4 I see no reason to upgrade. |
|
| Back to top |
|
|
voidengineer
n00b
Joined: 11 Feb 2005
Posts: 54
|
| Posted: Mon Jun 06, 2005 10:00 pm Post subject: |
|
|
| kill wrote: | | If it's not broke don't fix it. 2.6 has a much better layout, and better hardware support. As for being faster, that is debatable. If everything you have works fine with 2.4 I see no reason to upgrade. |
Umm, no it's not debatable. Quit spreading FUD, and get the facts straight.
| Code: |
Taken from http://kerneltrap.org/node/517
JA: Would it be safe to say that 2.5 will outperform even a heavily performance tuned 2.4?
Ingo Molnar: Id expect it to - if it does not at least give comparable performance for any given workload (with 2.5 tuned to that workload as well) then we have not done a good job.
JA: What other major improvements have gone into 2.5, beyond the scheduler and VM rewrites?
Ingo Molnar: the block IO rewrite, lots of VFS changes, a rework of the module code and (plug) the new threading implementation. The block IO rewrite was long overdue and that's the one Im most happy about.
|
And then a few changes noted; and shamelessly taken by me from http://zenii.linux.org.uk/~davej/docs/post-halloween-2.6.txt
| Code: |
IO subsystem.
~~~~~~~~~~~~~
- You should notice considerable throughput improvements over 2.4 due
to much reworking of the block and the memory management layers.
- Report any regressions in this area to Jens Axboe <axboe@suse.de>
and Andrew Morton <akpm@osdl.org>
- Two different IO elevators are available. The default is the
Anticipatory IO scheduler. You can select the deadline scheduler by
booting with "elevator=deadline" on the kernel command line.
- For some workloads the anticipatory scheduler is around 10% slower
than deadline. Most notably, database workloads which seek all over the
disk performing reads and synchronous writes. Database folks will likely
want to boot with elevator=deadline to get that last bit of performance back.
- Assorted changes throughout the block layer meant various block
device drivers had a large scale cleanup whilst being updated to
newer APIs.
- The size and alignment of O_DIRECT file IO requests now matches that
of the device, not the filesystem. Typically this means that you
can perform O_DIRECT IO with 512-byte granularity rather than 4k.
But if you rely upon this, your application will not work on 2.4 kernels
and will not work on some devices.
VM Changes.
~~~~~~~~~~~
- Version zero swap partitions are no longer supported (everything is
using v1 now anyway - rerun mkswap if in doubt).
Linux 2.0.x requires v0 swap space, Linux v2.1.117 and later
support v1. mkswap(8) can format swap space in either format.
- The actual 'reverse mappings' part of Rik van Riel's rmap vm was merged.
VM behaviour under certain loads should improve.
- VM misbehaviour should be reported to linux-mm@kvack.org
- The VM explicitly checks for sparse swapfiles, and aborts if one is found.
- /proc/sys/vm/swappiness defines the kernel's preference for pagecache over
mapped memory. Setting it to 100 (percent) makes it treat both types of
memory equally. Setting it to zero makes the kernel very much prefer to
reclaim plain pagecache rather than mapped-into-pagetables memory.
- The bdflush() syscall is now officially deprecated. The syscall
does nothing, and prints a stern warning to users. The functionality
is replaced by the pdflush daemons.
- Due to various changes, swap files should be just as fast as swap partitions.
- In 2.4, up to 64 swap files were possible. In 2.6, this number is reduced
to 32. Like 2.4, these files can be up to 64GB in size, though you will
need a recent util-linux to have a mkswap utility that supports >2GB
Process scheduler improvements.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Another much talked about feature. Ingo Molnar reworked the process
scheduler to use an O(1) algorithm. In operation, you should notice
no changes with low loads, and increased scalability with large numbers
of processes, especially on large SMP systems.
- Scheduler is now Hyperthreading SMP aware and will disperse processes
over physically different CPUs, instead of just over logical CPUs.
- Robert Love wrote various utilities for changing behaviour of the
scheduler (binding processes to CPUs etc). You can find these tools at
http://tech9.net/rml/schedutils
- The behavior of sched_yield() changed a lot. A task that uses
this system call should now expect to sleep for possibly a very
long time. Tasks that do not really desire to give up the
processor for a while should probably not make heavy use of this
function. Unfortunately, some GUI programs (like Open Office)
do make excessive use of this call and under load their
performance is poor. It seems this new 2.6 behavior is optimal
but some user-space applications may need fixing.
- The above applies to use of yield() in the kernel, too.
- 2.6 adds system calls for manipulating a task's processor
affinity: sched_getaffinity() and sched_setaffinity()
- Regressions to mingo@redhat.com and rml@tech9.net
- Debian users who encounter effects such as skips in mp3
playback, jerky mouse movement may want to stop the
X server from renicing itself to -10
You can alter this permanently with 'dpkg-reconfigure xserver-common';
if you elect not to have /etc/X11/Xwrapper.config managed by debconf,
simply edit it directly.
- Balancing of IRQs between multiple CPUs should be handled using the
irqbalance (http://people.redhat.com/arjanv/irqbalance/) program.
- David Mosberger maintains a webpage containing some current 'known gotchas'
of the O(1) scheduler at http://www.hpl.hp.com/research/linux/kernel/o1.php
Process scheduler improvements.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Another much talked about feature. Ingo Molnar reworked the process
scheduler to use an O(1) algorithm. In operation, you should notice
no changes with low loads, and increased scalability with large numbers
of processes, especially on large SMP systems.
- Scheduler is now Hyperthreading SMP aware and will disperse processes
over physically different CPUs, instead of just over logical CPUs.
- Robert Love wrote various utilities for changing behaviour of the
scheduler (binding processes to CPUs etc). You can find these tools at
http://tech9.net/rml/schedutils
- The behavior of sched_yield() changed a lot. A task that uses
this system call should now expect to sleep for possibly a very
long time. Tasks that do not really desire to give up the
processor for a while should probably not make heavy use of this
function. Unfortunately, some GUI programs (like Open Office)
do make excessive use of this call and under load their
performance is poor. It seems this new 2.6 behavior is optimal
but some user-space applications may need fixing.
- The above applies to use of yield() in the kernel, too.
- 2.6 adds system calls for manipulating a task's processor
affinity: sched_getaffinity() and sched_setaffinity()
- Regressions to mingo@redhat.com and rml@tech9.net
- Debian users who encounter effects such as skips in mp3
playback, jerky mouse movement may want to stop the
X server from renicing itself to -10
You can alter this permanently with 'dpkg-reconfigure xserver-common';
if you elect not to have /etc/X11/Xwrapper.config managed by debconf,
simply edit it directly.
- Balancing of IRQs between multiple CPUs should be handled using the
irqbalance (http://people.redhat.com/arjanv/irqbalance/) program.
- David Mosberger maintains a webpage containing some current 'known gotchas'
of the O(1) scheduler at http://www.hpl.hp.com/research/linux/kernel/o1.php
Process scheduler improvements.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Another much talked about feature. Ingo Molnar reworked the process
scheduler to use an O(1) algorithm. In operation, you should notice
no changes with low loads, and increased scalability with large numbers
of processes, especially on large SMP systems.
- Scheduler is now Hyperthreading SMP aware and will disperse processes
over physically different CPUs, instead of just over logical CPUs.
- Robert Love wrote various utilities for changing behaviour of the
scheduler (binding processes to CPUs etc). You can find these tools at
http://tech9.net/rml/schedutils
- The behavior of sched_yield() changed a lot. A task that uses
this system call should now expect to sleep for possibly a very
long time. Tasks that do not really desire to give up the
processor for a while should probably not make heavy use of this
function. Unfortunately, some GUI programs (like Open Office)
do make excessive use of this call and under load their
performance is poor. It seems this new 2.6 behavior is optimal
but some user-space applications may need fixing.
- The above applies to use of yield() in the kernel, too.
- 2.6 adds system calls for manipulating a task's processor
affinity: sched_getaffinity() and sched_setaffinity()
- Regressions to mingo@redhat.com and rml@tech9.net
- Debian users who encounter effects such as skips in mp3
playback, jerky mouse movement may want to stop the
X server from renicing itself to -10
You can alter this permanently with 'dpkg-reconfigure xserver-common';
if you elect not to have /etc/X11/Xwrapper.config managed by debconf,
simply edit it directly.
- Balancing of IRQs between multiple CPUs should be handled using the
irqbalance (http://people.redhat.com/arjanv/irqbalance/) program.
- David Mosberger maintains a webpage containing some current 'known gotchas'
of the O(1) scheduler at http://www.hpl.hp.com/research/linux/kernel/o1.php
|
And on and on and on . . .
And honestly http://www.fuckinggoogleit.com/
There is sh*t loads of information on the web. Honestly asking whether or not one should upgrade to a 2.6 kernel is just condescending. [/url] |
|
| Back to top |
|
|
kill
Apprentice
Joined: 25 Dec 2004
Posts: 179
|
| Posted: Tue Jun 07, 2005 2:21 am Post subject: |
|
|
Maybe you should do a little real world research before you start acting like an idiot.
And as your own qotes show
| Code: | JA: Would it be safe to say that 2.5 will outperform even a heavily performance tuned 2.4?
Ingo Molnar: Id expect it to
|
He expects it to not it does or will.
The 2.6 series has been benchmarked vs the 2.4 series by
KERNEL DEVELOPERS and the results clearly show that all those improvements are not all they're cracked up to be. Just because some code was changed to increase performance does not mean that's what ended up happening. So now how about you quit acting like a moronic fan boy. |
|
| Back to top |
|
|
nxsty
Veteran
Joined: 23 Jun 2004
Posts: 1556
Location: .se
|
| Posted: Tue Jun 07, 2005 4:26 pm Post subject: |
|
|
| Sure a very tweaked and patched 2.4 kernel could probably perform as good as 2.6 does normaly but usually 2.6 outperforms 2.4 in almost any situation. The 2.4 kernel they benchmarked was from RHEL and it contains backported NPTL and the O(1) scheduler among other things which the vanilla 2.4 kernel doesen't have. |
|
| Back to top |
|
|
kill
Apprentice
Joined: 25 Dec 2004
Posts: 179
|
| Posted: Tue Jun 07, 2005 6:47 pm Post subject: |
|
|
Yes a few things were backported. But if you had looked at the results you would have seen that the performance improvement between 2.6 releases is very much varied.
| Quote: | | " In their benchmarks, 2.6.9 performed 6% slower than their baseline in database transaction testing, 2.6.8 performed 23% slower, and 2.6.2 only 1% slower." |
I wouldn't claim that 2.6 outperforms 2.4 when there is as high as a 22% difference, not for the better, between a few minor releases in the 2.6 branch. That alone tells me that the 2.6 branch's performance is highly debatable. |
|
| Back to top |
|
|
nxsty
Veteran
Joined: 23 Jun 2004
Posts: 1556
Location: .se
|
| Posted: Tue Jun 07, 2005 7:30 pm Post subject: |
|
|
Yes, but that's only database performance on a 4 way itanium2 system. This doesen't necessarily mean that performance overall has become worse. It could be just a itanium regression, a SMP regression or another regression that perhaps moslty affect database loads. Performance in other workloads could actually have been improved. In my experience multimedia performance and desktop interacitvity have only become steadily better which each release and there is a huge difference against 2.4. You should try it if you haven't already.  |
|
| Back to top |
|
|
songpenguin
Tux's lil' helper
Joined: 21 Jun 2005
Posts: 142
Location: USA
|
| Posted: Thu Jul 21, 2005 11:57 pm Post subject: |
|
|
Try it, it's not hard and you can always go back. IMHO 2.6 is WAY faster than 2.4. Also it has goodies like ALSA in the kernel, etc... It's just faster for me.
--
Songpenguin
_________________
Bill, I don't do Windows. --Ray Bradbury
You've got to jump off cliffs and build your wings on the way down. --Ray Bradbury |
|
| Back to top |
|
|
platojones
Veteran
Joined: 23 Oct 2002
Posts: 1602
Location: Just over the horizon
|
| Posted: Fri Jul 22, 2005 12:03 am Post subject: |
|
|
| Wow, the simple answer is "You really don't have a choice, eventually". 2.4 is in bug fix only mode now and that will soon stop. What that means is that it is unlikely that 2.4 will ever be updated for hardware, etc. 2.6 is not only the future, it is the now. Might as well bite the bullet and go for it. |
|
| Back to top |
|
|
katsiki
Apprentice
Joined: 14 Jun 2005
Posts: 233
Location: Pasadena, CA (USA)
|
| Posted: Fri Jul 22, 2005 12:07 am Post subject: |
|
|
My ancient 486-DX2 is probably stuck at 2.4. I don't expect this system will ever be able to run 2.6. It is too quirky, and it is unlikely anyone would invest the effort to figure out how to make it work.
For current machines, 2.6.x will be nice even for just the udev features, once all the bugs finally get worked out. |
|
| Back to top |
|
|
Drunkula
Apprentice
Joined: 28 Jul 2003
Posts: 257
Location: Denton, TX - USA
|
| Posted: Fri Jul 22, 2005 2:06 pm Post subject: |
|
|
Try looking at this this way: Is there any reason to stay at 2.4?
|
|
| Back to top |
|
|
katsiki
Apprentice
Joined: 14 Jun 2005
Posts: 233
Location: Pasadena, CA (USA)
|
| Posted: Fri Jul 22, 2005 6:33 pm Post subject: |
|
|
| Is writing device drivers for industrial applicattions easier to support under 2.4 than 2.6? I have no idea, but sometime I will need to find out. |
|
| Back to top |
|
|
|
Kernel & Hardware
