IRC channel logs
2023-01-09.log
back to list of logs
<gnucode>Aurora_v_kosmose: there's always netsurf. :) <gnucode>Though it's hard to do anything with that browser...thought I am happy it exists. <old>dsmith-work: Lok what where does it says that? <old>Aurora_v_kosmose: Tell me about it. I used to be able to compile it when I had 64 GB. Now I'm at 24 and the OOM killer is hungry <Aurora_v_kosmose>You can get a lot done with zram + zstd + a backing device for uncompressable pages, but it still sucks. <Aurora_v_kosmose>The latest idle huge pages patches for zram are also not in my kernel because Debian. :/ <old>Is zram avaible for Guix? <old>that could be useful <old>In the meantime, I use substitutes instead of compiling it <old>Okay I will see to that! <old>at the expense of much computation power? <old>I don't know the internal details of zram, but I guess that if its involve compression such as Ziv, then you might get a few more degree on the thermometer <Aurora_v_kosmose>You can tune which compression algorithm you use. I use zstd because it has decent performance, but you can use lzo if you want. <nckx><That's incidentally why I've stopped using zswap as well.> What's ‘that’ here, exactly? <old>sounds a good thing to have <old>I have a very decent cooler that does not make any noise so I don't mind <old>But I often do micro-benchmark at the nanosecond scale. If I can disable it through kernel CLI then I'm happy with it <Aurora_v_kosmose>zswap can scrape around 4x with significant drawbacks once you go past 2x. <old>oh can you disable it before kernel boot? <nckx>Aurora_v_kosmose: Why's that? <old>I meant, toggling it after kernel boot <Aurora_v_kosmose>nckx: Very different storage strategy. zswap did fancy things in the swap subsystem directly with a cache, while zram just uses a relatively plain compressed ramdisk <nckx>ACTION has at this moment a zswap compression ratio of exactly 4.00, I kid you not :) <nckx>Right, but what kind of performance differences do you see? <nckx>Especially at that 2x inflection point and why? <nckx>I've read it, but thanks. <Aurora_v_kosmose>In terms of practical differences, I can have a swapless VM suddently have 1.5x - (~5%) as much memory as normal. Before adding a backing device for more conventional swapout of idle pages from the zram devices. <nckx>I'm guessing you mean the allocator switch from zbud to (say) zsmalloc, not a change when compression actually hits >2x, right? <Aurora_v_kosmose>nckx: Indeed. Even if the compression is better zbud won't give you anything more than 2x at most. <nckx>Well, true, but you wouldn't use zbud with zstd anyway. <Aurora_v_kosmose>I suppose if your CPU is already a bottleneck for most of your uses, then compressed swap isn't a great offering. In my case motherboard support for more memory is the bottleneck I'm hitting first. <akirakyle>daviid: It looks like your fixes are working for me so far! Thanks! <nckx>Same, although the 16 GiB max isn't too bad. Still nice to be able to compile Web browsers & use one at the same time. : <Aurora_v_kosmose>I've got a dormant Guile script I'll finish when Debian finally updates its kernel for the newer features of zram. <nckx>I guess I'll give zram another chance when they land here (if they haven't already). <nckx>Ooh, thanks. I have that commit… :}