Five Years Of Linux Kernel Benchmarks: 2.6.12 Through 2.6.37

[Guest]

The resources that are required to maintain these products would be better put towards common hardware in use.

No, an old drivers rarely needs updates.

It would also decrease compilation time,

You do not need to compile it. You can disable old drivers in config

ease configuration options,

not quite

reduce code complexity, and start bringing down the kernel to a reasonable size again on "in the can" distros.

it really does not matter

Lets face it, many distro's advertise minimum requirements that often exceed the capabilities of any hardware that would still have support for these products such as ISA solutions, micro-channel support, tolkien ring, etc.

AFAIR ISA code is still needed for PCI, PCI is still needed for PCIexpress.

I'm not sure if it's possible to remove isa even on x86_64. Zone DMA probably still has to be supported.

[Guest]

The resources that are required to maintain these products would be better put towards common hardware in use. It would also decrease compilation time, ease configuration options, reduce code complexity, and start bringing down the kernel to a reasonable size again on "in the can" distros. Lets face it, many distro's advertise minimum requirements that often exceed the capabilities of any hardware that would still have support for these products such as ISA solutions, micro-channel support, tolkien ring, etc.

BTW. The best would you do if asked about it at LKML - there, you'll get the most competent answers.

[deanjo]

BTW. The best would you do if asked about it at LKML - there, you'll get the most competent answers.

Did long time ago and it was doable. Would have been easier however when x86 and x86-64 were still separate code bases.

[deanjo]

No, an old drivers rarely needs updates.

Old drivers are quite often updated. One only needs to look at the alsa release logs there to see that.

You do not need to compile it. You can disable old drivers in config

Never said you couldn't however the trend for pre-compiled kernel configs is to modularize everything including the kitchen sink.

not quite

I really beg to differ, reducing the legacy hardware support would trim the config tree considerably.

it really does not matter

Sure it does, especially where installation / live media is concerned plus it would ease the burden on users that do not have a good high speed link.

AFAIR ISA code is still needed for PCI, PCI is still needed for PCIexpress.

I'm not sure if it's possible to remove isa even on x86_64. Zone DMA probably still has to be supported.

I'm talking more of ISA devices such as ISA video cards, ISA sound cards, ISA network cards, etc etc.

[zouboulou]

Did long time ago and it was doable. Would have been easier however when x86 and x86-64 were still separate code bases.

and would bring no real big benefits.

[deanjo]

and would bring no real big benefits.

Reducing code size and complexity always has it's benefits from a developer and auditor point of view.

[EarthMind]

Why no PostgreSQL benchmarks? Me is sad

[Zhick]

Interesting that also, Intel corp, has confirmed that Linux is getting slower and slower. Maybe this is because Linux is getting more and more bloated?

Uhm did you even have a look at the results? I got the impression that performance actually mostly improved.

[deanjo]

Uhm did you even have a look at the results? I got the impression that performance actually mostly improved.

Well that depends I guess if you call resuming performance after a regression an "improvement". The only conclusion that I can really see is it depends on what performance you are looking at. Overall it's about the same IMO with a few exceptions.

[kebabbert]

Uhm did you even have a look at the results? I got the impression that performance actually mostly improved.

Yes I looked at every result. I suggest you look again.


Now the 10 year old BKL is dealt with. That is good. Maybe Linux will soon start to scale better than today?

http://www.mattheaton.com/?p=222

"If linux wants to scale efficiently to 16,32,64 cores then the scheduler needs some serious work."