IRC channel logs


back to list of logs

<Aurora_v_kosmose>Yeah, compiling large C++ projects is harsh on resources or time.
<Aurora_v_kosmose>Firefox is another one that's completely absurd to build.
<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.
<Aurora_v_kosmose>I'm fond of Eww and Nyxt.
<old>dsmith-work: Lok what where does it says that?
<old>Oh I see
<old>well that sucks
<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
<Aurora_v_kosmose>It should be, it's a built-in kernel module, normally.
<old>In the meantime, I use substitutes instead of compiling it
<old>Okay I will see to that!
<Aurora_v_kosmose>I can get up to 5x compression with it, so it tends to help a bunch.
<Aurora_v_kosmose>That's incidentally why I've stopped using zswap as well.
<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>Sort of, but it doesn't seem to have too bad an impact.
<old>okay okay
<old>I will try it then
<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>oh neat
<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>nckx: The much higher compression ratio of zram.
<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 :)
<Aurora_v_kosmose>old: Sure, just swapoff the ramdisk & then unload it
<Aurora_v_kosmose>Debian has a systemd job for it.
<nckx>Right, but what kind of performance differences do you see?
<nckx>Especially at that 2x inflection point and why?
<Aurora_v_kosmose> The details are a bit complicated, so I'll defer to the official doc.
<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>That ~5% is what changes depending on the compression algorithm chosen.
<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. :
<nckx>* :)
<akirakyle>daviid: One thing I can't seem to easily figure out from the documentation is how to access constants. For example in the gdk docs, there's a whole bunch of constants for keys and such:
<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).
<Aurora_v_kosmose>nckx: These would be what I'm waiting for.
<nckx>Ooh, thanks. I have that commit… :}
<nckx>(And HPs.)
<Aurora_v_kosmose>Yup, if you're using 6.0+ you're fine.