On Thu, Jan 28, 2021 at 12:34 PM Alexander Bokovoy <abokovoy@xxxxxxxxxx> wrote: > > On to, 28 tammi 2021, Chris Murphy wrote: > >> >> > ram + zram + in-memory-zwap in the check. > >> >> > >> >> For bare metal IPA uses the python3-psutil call: > >> >> psutil.virtual_memory.available() > >> >> > >> >> I don't know how/if psutil reports zram (or cgroup v1 and v2 for that > >> >> matter). > >> > > >> > psutil (in general) reports data from /proc/meminfo; available come > >> > from MemAvailable: in that file. This is defined in kernel as: > >> > > >> >MemAvailable: An estimate of how much memory is available for starting new > >> > applications, without swapping. Calculated from MemFree, > >> > SReclaimable, the size of the file LRU lists, and the low > >> > watermarks in each zone. > >> > The estimate takes into account that the system needs some > >> > page cache to function well, and that not all reclaimable > >> > slab will be reclaimable, due to items being in use. The > >> > impact of those factors will vary from system to system. > >> > > >> >Notice "without swapping" in second line. Next question, how zram impacts > >> >reporting of MemAvailable by kernel? > >> > >> This is a good note. If zram breaks kernel API promise to user space > >> (/proc/meminfo is one such API), how can it be enabled by default. I > >> also would question enabling zram by default if it does not play along > >> with cgroups. We do depend on cgroups being properly managed by systemd, > >> including resource allocation. > >> > >> In my opinion, zram enablement in Fedora is quite premature. > >> > > > > > >It's the default Fedora wide since Fedora 33. It's been used by default in > >Fedora IoT since the beginning, and in openQA Anaconda tests for even > >longer than that. > > > >What's premature about it? > > I tried to point to my line of thought in the sentence above you quoted. > You might think that is irrelevant which thought I'd accept as an > argument and we can agree to disagree. Speculation is not an adequate explanation for calling the feature premature. /proc/meminfo MemTotal: 12158520 kB With no zram device versus a zram device sized 1:1 that of MemTotal MemAvailable: 11367156 kB MemAvailable: 11309564 kB And CommitLimit: 6079260 kB CommitLimit: 18237208 kB You can test this as easily as I can via 'systemctl start/stop swap-create@zram0' and see if it misaligns with expectations. I'm ignoring the cgroups complaint because there are other things that also don't work with cgroups ressource control that we're using in Fedora by default and I don't feel like beating up on those things, because while suboptimal it's also off topic for this problem. > Back to this subthread's topic. Looks like Adam found that something > did reduce a memory available to the system after standard install process > between Jan 24th and Jan 27th. Something did allocate ~120MB of RAM more > than it did previously on Fedora Server but also the kernel reports > ~600MB less RAM available even though in both cases QEMU was configured > with 2048MB RAM. OK I'm seeing this problem in a VM with Fedora-Workstation-Live-x86_64-Rawhide-20210128.n.0.iso but I'm not sure how consistent it is yet. MemTotal is ~3G for a VM that has 4G allocated. Something's wrong... VM 5.11.0-0.rc5.20210127git2ab38c17aac1.136.fc34.x86_64 [ 0.701792] Memory: 3016992K/4190656K available (43019K kernel code, 11036K rwdata, 27184K rodata, 5036K init, 31780K bss, 1173408K reserved, 0K cma-reserved) Baremetal 5.10.11-200.fc33.x86_64 [ 0.125875] Memory: 12059084K/12493424K available (14345K kernel code, 3465K rwdata, 9704K rodata, 2536K init, 5504K bss, 434080K reserved, 0K cma-reserved) Why is reserved so much higher in the VM case? It clearly sees the 4G but is delimiting it to 3G for some reason I don't understand. This is well before the zram module is loaded, by the way. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
