Five Years Of Linux Kernel Benchmarks: 2.6.12 Through 2.6.37

I guess we agree that we disagree.

agrees .

[deanjo]

No, I don't think so

I guess we agree that we disagree.

Maybe if they started reducing the code size, complexity and started concentrating on hardware in use that would change.

No, I don't think so

[deanjo]

No, from my POV the problem always was - too few people test development kernels and too few people fix bugs.

Everything else is just a stardust.

Maybe if they started reducing the code size, complexity and started concentrating on hardware in use that would change.

I think the problem isn't about how big or how many legacy features are in the kernel, but more about the new features which are placed on an old architecture, maybe flesystems are too different from 5 years ago and (corrrect me if not) the srtucture of the kernel hasn't changed that fast.

No, from my POV the problem always was - too few people test development kernels and too few people fix bugs.

Everything else is just a stardust.

[damipereira]

I think the problem isn't about how big or how many legacy features are in the kernel, but more about the new features which are placed on an old architecture, maybe flesystems are too different from 5 years ago and (corrrect me if not) the srtucture of the kernel hasn't changed that fast.

I'm very interested in seeing how the bisect is done.

Read git bisect --help

Or watch on youtube

If you can trace all of those old regressions (and subtract out the ones already fixed later), then we should be able to reclaim nearly any performance point we were at before while keeping modern improvements.

Partially you are right. I am afraid that it is not possible to reclaim nearly any performance point ie. huge changes O(1)->CFS, SLAB->SLUB etc. But for ordinary regression it is possible - it would great if someone could actively work on this. But I am afraid that nobody wants to pay for such work

[deanjo]

Hmmm... I think that you are missing a point here. Change in behavior of one function can affect other code that use this function. It's normal and you can not do anything about this. You can write unit test etc to detect breakage. Internal kernel API is fluent and such situations are normal.

Not missing the point at all. Bottom line is that it still requires more work then necessary to accommodate such changes and adds to the workload which often would not be required with a reduced code base.

When coding is done right it has to be done so that making a change does not cause issues with other code.

Hmmm... I think that you are missing a point here. Change in behavior of one function can affect other code that use this function. It's normal and you can not do anything about this. You can write unit test etc to detect breakage. Internal kernel API is fluent and such situations are normal.

Having to worry about that can complicate fixes and create unforeseen issues all for the sake of maintaining compatibility for items that only the rare few utilize. Often comprises are made for the sake of compatibility while sacrificing performance.

[deanjo]

There is another proprietary OS i know that needs more and more resources with every upgrade. Linux kernel on the other hand, needs almost the same, despite having added much more features in 5 years...

Guess that depends if your comparing kernels or the complete OS. Linux as a complete OS has gone up in system requirements as well over the years where as that "other OS" kernels have been developing on reducing their kernel requirements.