Announcement

Collapse
No announcement yet.

Five Years Of Linux Kernel Benchmarks: 2.6.12 Through 2.6.37

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by damipereira View Post
    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.

    Comment


    • #32
      Originally posted by michal View Post
      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.

      Comment


      • #33
        Originally posted by deanjo View Post
        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

        Comment


        • #34
          Originally posted by michal View Post
          No, I don't think so
          I guess we agree that we disagree.

          Comment


          • #35
            Originally posted by deanjo View Post
            I guess we agree that we disagree.
            agrees .

            Comment


            • #36
              Michael, I don't see any of the observed regressions being bisected and reported to https://bugzilla.kernel.org/

              If you really intend helping Linux development, please, at least find bad commits, people like me can report it to the kernel bugzilla. I will do that willingly.

              Comment


              • #37
                Originally posted by birdie View Post
                Michael, I don't see any of the observed regressions being bisected and reported to https://bugzilla.kernel.org/

                If you really intend helping Linux development, please, at least find bad commits, people like me can report it to the kernel bugzilla. I will do that willingly.
                Read the article:

                For some of these regressions, we will be reporting on their precise causes in a future article; seeing as, after all, we are funded by advertising with page views plus premium subscriptions, PayPal tips (also in the form of Augustiner beer at Oktoberfest), and affiliate shopping links. One of the many Phoronix Test Suite capabilities is the ability to automatically bisect a Git tree (and other revision control systems) looking for performance and functional regressions, which we have already used to find performance regressions within the Linux kernel down to the precise commit in an automated manner. Combine these modularized capabilities plus those from other Phoronix Test Suite and Phoromatic features we will make public in the near future and to professional customers, it becomes a powerful utility to trivially locate such issues with little manual intervention on the user's part.
                Michael Larabel
                http://www.michaellarabel.com/

                Comment


                • #38
                  Originally posted by snadrus View Post
                  I'm very interested in seeing how the bisect is done. 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.
                  Unlikely. A regression is an unexpected change in behavior. On bisection, it is likely that the changes will be either planned or unplanned. The planned changes are no longer regressions by definition .

                  The planned changes (ie: a conscious trade-off by a developer to get a more general benefit) are unlikely to be regained simply. The unplanned changes that caused regressions are a different story. Some may be reclaimable, other may not. Understanding the reason for the regression in that case will be where the most value is extracted.

                  Comment


                  • #39
                    Ideally it would be possible to run Ubuntu on a 486 without any problems.

                    But that isn't possible because of userspace bloat the kernel itself should run more or less fine (if you remove uneeded modules etc...)

                    I have friends that ran X11 + linux on 486s back in the day with as little as 4 Mb ram sure it wasn't high res but it worked and I doubt the current X.org could do that as well.

                    I really don't seen the need for the use of exorbitant amounts of ram as current graphics toolkits and software do.

                    Some of you have asked for droping of kernel support for old hardware... well that is exactly what has been done on the userspace side... are you happy with how that it turning out?

                    Comment


                    • #40
                      Michael,

                      Thank you! I'm sorry for not reading very carefully.

                      Comment


                      • #41
                        cb88,

                        Why do you need to run the latest and greatest software on your ancient hardware? Run kernel 2.4 which works very well. And I doubt you'll need to run any modern desktop software like word processors or web browsers. You see, the web has evolved a lot for the last ten years. Old web browsers won't be able to render correctly most modern popular web sites.

                        So, either run old software on your old hardware or find another thing to do.

                        After all people are not complaining they cannot ride horses in modern cities. The world is evolving rapidly. Live with that or perish.

                        Comment


                        • #42
                          Heck, you can run recent linux kernel and full-featured userspace with all the eye-candy in mobile phones. Or in basic wireless routers with 8MB ram and 2 MB flash (without the eye-candy obviously).
                          Linux kernel getting more bloatet isn't huge problem (or even problem at all).

                          Comment


                          • #43
                            Originally posted by birdie View Post
                            cb88,

                            Why do you need to run the latest and greatest software on your ancient hardware? Run kernel 2.4 which works very well. And I doubt you'll need to run any modern desktop software like word processors or web browsers. You see, the web has evolved a lot for the last ten years. Old web browsers won't be able to render correctly most modern popular web sites.

                            So, either run old software on your old hardware or find another thing to do.

                            After all people are not complaining they cannot ride horses in modern cities. The world is evolving rapidly. Live with that or perish.
                            I think you missed the point...They were referring to efficiency. Not age.

                            There seems to be a weird habit of programmers bloating things up for no reason other than to "take advantage of new hardware". ie: no longer care about efficiency, and features become the priority...It results in sloppy programming practices.

                            To be honest, if you have a choice between bloat or "lean and mean"; which would you go for? Most people would go for the latter when there is an option to do so.

                            Then again, not all things modern have been beneficial to humanity...It has even caused consequences which many rather not admit. So we end up treating symptoms.

                            Comment


                            • #44
                              Originally posted by aussiebear View Post
                              There seems to be a weird habit of programmers bloating things up for no reason other than to "take advantage of new hardware". ie: no longer care about efficiency, and features become the priority...It results in sloppy programming practices.
                              I really don't think you'll find very much of that among kernel developers. That's why they are kernel developers and not writing websites or desktop apps, and if you read through the kernel mailing lists i think you'll find that there isn't a whole lot of tolerance there for people who write bad code.

                              Comment


                              • #45
                                god help the linux kernel

                                Comment

                                Working...
                                X