Announcement

Collapse
No announcement yet.

Multigenerational LRU Code Updated For Enhancing Linux Kernel Performance

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

  • Multigenerational LRU Code Updated For Enhancing Linux Kernel Performance

    Phoronix: Multigenerational LRU Code Updated For Enhancing Linux Kernel Performance

    Last month Google engineers proposed multi-generational LRU for Linux to enhance the kernel performance and today the work has advanced to a second version...

    https://www.phoronix.com/scan.php?pa...ational-LRU-v2

  • #2
    I don't like Google or their business model. But their Linux engineers are some of the best.

    Comment


    • #3
      from the article:
      "Android... " "less cold starts"
      Wait. Isn't that a bit much? I know (and have experienced) OOM issues (back in the days when I thought 4 GiB were fine, even today with 16 GiB... but usually it kills the very memory eater. This is in my case usually a browser with many tabs, or the compiler session (that runs in /var/tmp/portage). Thus I have this nasty unresponsibility, the HDD/SSD LED on constantly, and know, darn, out of mem and swap. Wait some time and usually it kills off something to return to normal.
      But a complete restart? Sounds like either a bit much, or the OOM killer is kicking some vital Android parts. That shouldn't be.

      The next big issue: Why do we run OOM? Because SW becomes more and more sloppily coded. Abstraction layers, frameworks, virtualisations, dependencies and simply sloppy code that never gets polished. Ah, memory leak, who cares. People won't run that program for longer than, uh, 15 minutes, right?
      :P This sucks.
      Stop TCPA, stupid software patents and corrupt politicians!

      Comment


      • #4
        Originally posted by Adarion View Post
        from the article:
        "Android... " "less cold starts"
        Wait. Isn't that a bit much? I know (and have experienced) OOM issues (back in the days when I thought 4 GiB were fine, even today with 16 GiB... but usually it kills the very memory eater. This is in my case usually a browser with many tabs, or the compiler session (that runs in /var/tmp/portage). Thus I have this nasty unresponsibility, the HDD/SSD LED on constantly, and know, darn, out of mem and swap. Wait some time and usually it kills off something to return to normal.
        But a complete restart? Sounds like either a bit much, or the OOM killer is kicking some vital Android parts. That shouldn't be.

        The next big issue: Why do we run OOM? Because SW becomes more and more sloppily coded. Abstraction layers, frameworks, virtualisations, dependencies and simply sloppy code that never gets polished. Ah, memory leak, who cares. People won't run that program for longer than, uh, 15 minutes, right?
        :P This sucks.
        Cold starts of apps, not phones

        Definitions of cold/hot/warm starts: https://developer.android.com/topic/...ls/launch-time

        Comment


        • #5
          Typo: "~96% fewwer low-memory tab discards"

          Comment

          Working...
          X