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
                https://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

                      Working...
                      X