Announcement

Collapse
No announcement yet.

"le9" Strives To Make Linux Very Usable On Systems With Small Amounts Of RAM

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

  • #61
    Originally posted by tedesign View Post
    As I'm not skilled enough in systems programming, can someone please explain to me what the catch is (if there's any one at all)?
    There's none, for what we know currently. This patch makes Linux prefer swapping anonymous memory (regular program memory) more than evicting file cache of a defined size, unless you're really low on RAM+swap (vm.clean_low_kbytes le9 tunable), or doesn't evict at all (vm.clean_min_kbytes tunable).
    The last parameter (min) could create issues, at least with Intel graphics. Hakavlad believes this is i915 driver issue which is triggered by le9 patch, and not the patch fault per se (but this to be investigated deeper).
    My ISO image does not set vm.clean_min_kbytes tunable and should not trigger any bugs.

    Originally posted by tedesign View Post
    From what I think I've understood, the worst scenario you can expect is that the system will gracefully close random processes (in the browser's case the tabs), before it starts dumping in swap like mad and becoming completely unresponsive (and losing ALL the processes with a hard reboot). Is there any risk of memory corruption (other than what may happen to the shut-down user space processes) or other damage or risks at a system and file system level?
    Well, the system behavior is basically the same as without the patch: if you're really low on memory, so low that the system can't continue working properly anymore, the kernel's OOM (out-of-memory) killer should kill (the most RAM consuming) process. The thing is, regular OOM invocation is too slow, the system usually freezes due to thrashing for several minutes before OOM is triggered to kill something.
    With this patch OOM is triggered much faster, just because it prevents hard thrashing in the first place.
    Unresponsive or frozen system on near-full RAM on stock kernel vs responsive and faster process killing with le9.

    Originally posted by tedesign View Post
    If this is indeed the case, I really wonder why this approach and patch aren't immediately reviewed by the Linux Kernel Team and adopted, if found safe and secure.
    The somewhat similar patch in used in ChromeOS by Google for over a decade, and it's been published to Linux review but didn't get enough attention I guess.
    I want to help hakavlad to write an ideal and comprehensible post to linux-mm list, with all the synthetic and real world tests. For this, I bought this low-end PC from the article to test everything myself and check how good this feature work. I would like to record and provide video comparison to demonstrate desktop performance speedup, as well as PSI records etc what kernel people expect.


    Originally posted by tedesign View Post
    PS are you completely sure that it is not worthwhile trying on 32-bit systems? I have an old Asus 32bit 900mhz 1GB eeePC that might rise from the ashes, perhaps with an even lighter DE than XFCE. Could this also apply to ARM boards (like the RPi or the BBB)? It would be awesome if you, ValdikSS, with your great clarity and when comfortable, would provide a step-by-step guide (including parameters optimization for the different architectures), to integrate this patch in any distribution and architecture one may need.
    Oh man, EEEPC 900 was not enough powerful even back in its day (I had one, this was my first laptop ever!). IMO it's not worth it. It sure will work, but it would be too slow for comfortable internet surfing today.
    Le9 should work great on SBCs though, especially since we're slowly moving to fully-working desktop experience thanks to Panfrost.
    Last edited by ValdikSS; 16 July 2021, 01:03 PM.

    Comment


    • #62
      Originally posted by LinAGKar View Post

      Redis AOF for everything?
      Basically yes, I wrote a sample editor and a AmigaGuide editor using that technique back in the 90:ies on the Amiga in assembler, one would have imagined that we would have progressed since then and not regressed

      Comment


      • #63
        Originally posted by ssokolow View Post

        As long as you implement an OS/platform-level analogue to Private Browsing Mode so I don't have to wind up using Firejail or Flatpak or something like that just to ensure I can get plug-pull erasure when I want it.
        Should be no problem, on the other hand why are you editing documents with no intention to have the changes stored? I might imagine that you would want some intermediate changes removed for various reasons but that would be a simple "merge history" command or something.

        At least LibreOffice does an autosave every 5 minutes but lots of things can happen in those 5 minutes, and don't get me started with all those games with their "when this symbol is displayed the game is saving so whatever you do do not turn your system off when that happens" - so they don't even do the old fashion proper way of fopen->fwrite->fsync->fclose->rename. Computer users are conditioned to take way too much shit.

        Comment


        • #64
          Originally posted by F.Ultra View Post
          Should be no problem, on the other hand why are you editing documents with no intention to have the changes stored? I might imagine that you would want some intermediate changes removed for various reasons but that would be a simple "merge history" command or something.
          Similar reason to why I use Private Browsing Mode. Scratchpads for porny stuff that I don't want to admit to.

          Originally posted by F.Ultra View Post
          At least LibreOffice does an autosave every 5 minutes but lots of things can happen in those 5 minutes
          True. I think I might have changed LIbreOffice's auto-save to once every minute, but I generally write in something like Markdown or reStructuredText in something like Vim or FeatherPad, so I open it too infrequently to remember for certain.

          Originally posted by F.Ultra View Post
          and don't get me started with all those games with their "when this symbol is displayed the game is saving so whatever you do do not turn your system off when that happens" - so they don't even do the old fashion proper way of fopen->fwrite->fsync->fclose->rename. Computer users are conditioned to take way too much shit.
          Reminds me of how, to resolve that as well as bugs that would exist regardless of the intended approach, I plan to incorporate automatic snapshotting support into the game launcher I really need to get back to working on.

          Comment


          • #65
            Originally posted by perpetually high View Post
            I've been using this patch!! =) Works on 5.4 LTS too. I didn't know about the le9db GitHub repo.

            Sorry if I'm being annoying- but within the past week, I've been tweaking some heavy kernel config settings (and this was already after tons and tons of tweaking) and I added a bunch of new zen/cfs/xanmod tweaks, and my god, my system is FLYING. The 5.4 LTS kernel is a big part of this too if you're on older hardware like Polaris, give it a shot.

            I might make a guide soon. Sirlucjan, xanmod, these guys are all providing some excellent patches to make the kernel lightening fast. And of course Michael for giving the 4-1-1. I appreciates.
            Wow thank you for the tip! I'm trying xanmod kernel and it is amazing, not only in speed, but memory usage as well. I don't know how, but I'm using something like half of my normal memory usage.

            Comment


            • #66
              Originally posted by krzyzowiec View Post

              Wow thank you for the tip! I'm trying xanmod kernel and it is amazing, not only in speed, but memory usage as well. I don't know how, but I'm using something like half of my normal memory usage.
              Awesome, you're welcome. The xanmod kernel is fantastic, and he has almost all the great patches/tweaks (though I don't agree with using a full tickless @ 500 hz. Idle tickless @ 1000 hz low-latency preempt is still the way to go and I can prove it), and he compiles like 10 different versions for whatever your situation. He's great.

              And the performance gains are not just in your head: phoronix article on xanmod

              Literally everyone should be running some variant of the xanmod kernel if they're not compiling their own tweaked-out kernel on steroids (i.e., me)

              Bunch of people liked my earlier post about making that guide on compiling your own tricked-out kernel. I really might need to. I've learned *a lot* about tweaking and performance and it'd be selfish to keep it to myself. But I also don't want to deal with anyone's bs so I might just drop tid bits here and there, we'll see.

              tl;dr use the xanmod kernel!! (preferably 5.13.2-xanmod1-edge) and also preload (look it up, or sudo apt install preload). Stay woke y'all

              Comment


              • #67
                tl;dr use the xanmod kernel!!
                I've installed xanmod kernel (Fedora) for the first time approx a month ago and since then I had 0 xruns with Pipewire (using USB Audio). Sadly kernel 5.14-rc1 didn't fix xruns for me with its reduced USB-Audio driver latency.

                Comment


                • #68
                  Originally posted by 131313 View Post
                  I've installed xanmod kernel (Fedora) for the first time approx a month ago and since then I had 0 xruns with Pipewire (using USB Audio). Sadly kernel 5.14-rc1 didn't fix xruns for me with its reduced USB-Audio driver latency.
                  I see. I don't know much about the situation you're referring to, but let me suggest the LTS 5.4 kernel. I can't rave enough about how great of a kernel it is. It's noticeably faster on my Polaris/Haswell machine. Really recommend everyone give it a shot.

                  Link to the latest version as of today: https://kernel.ubuntu.com/~kernel-pp...line/v5.4.132/

                  And just grab the *.deb's (generic or low-latency) under amd64. I'd be curious if that fixes your problem

                  Comment


                  • #69
                    We are waiting for the patch to be added to zen-kernel https://github.com/zen-kernel/zen-kernel/issues/218

                    upd: https://github.com/zen-kernel/zen-ke...b99540e3b8ea9b
                    Last edited by hakavlad; 17 July 2021, 03:13 PM.

                    Comment


                    • #70
                      ValdikSS, thank you for your kind replies and technical clarification. You might be right about the 900Mhz eeePC being somewhat underpowered by today's standards, however I still believe that providing an i386.iso (if technically feasible) to try on 32-bit legacy systems (not just on this one) still has some technical and practical merit, especially in the context of free software. I would also consider that testing the patch in different architectures would extend its scrutiny and, possibly, its general validity (also good for integration in the mainline advocacy) and I suspect that it could shine even more in that case, given that 32-bit architectures should be less memory hungry and, therefore, make the performance look even better on systems with very low RAM. Some SBCs are still 32-bit and, even though most of them would be headless, they could still be a nice playing ground to test the patch running applications other than browsers.

                      PS I'm about to try (first in live mode using your ISO) the patched XanMod kernel on my Sandy Bridge I7, but I'm a little bit worried by what you described as the i915 driver bug. I tried to understand the problem on the XanMod forum thread, but there isn't much information on its manifestation and possible mitigation. Could you take a moment to clarify and instruct? Is it safe to switch to XanMod kernel if it shows no problems running the ISO live?

                      Comment

                      Working...
                      X