2017-02-15 11:33 GMT+01:00 Peter Robinson <[email protected]>: > >> We lose some ram on aarch64 due to cma allocation, its something that is > >> actively being looked at. Anaconda also needs a fair amount of ram > during > >> the network install to copy files. Once the install is complete, you > should > >> be able to reduce the ram to 2048. > > > > 2G not being enough is pretty excessive. I never had such problems on > > x86. Only recently (a year ago or so) I started using 2G for guests, 1G > > used to be enough even for network installs. > > Completely agree, generally if you're doing a anaconda based install > you need at least 768Mb due to various combinations of installer > memory usage and selinux applying policies. > That's true. If you're looking for smallest memory usage during installation possible, use NFS installation source (or ISO or ISO over NFS). That way, install.img (anaconda rootfs - 378MiB large in case of F25) is mounted directly from nfs shares and packages are also used directly from NFS, no copying to local / (which is using memory through device-mapper). HTTP installation consumes the most memory, since it's copying install.img and other stuff to local / (again in memory). Afaik RHEL-7 has 1G requirement for NFS installation and 2G for HTTP installation. The last thing you want to happen is to have OOM during installation :)
> > I suspect a big factor here is CONFIG_ARM64_64K_PAGES=y. Raspberry pi > > 3, with standard fedora kernel (64k pages), minimal install (@core), > > booted to the shell prompt. "free" reports ~122MB of memory as used. > > Same with a self-compiled kernel (4k pages), I get ~44MB of used memory. > > That is almost factor three! > > That is almost the complete factor. It's in fact a combination of 64K > pages and CMA. The two together mean that the minimum CMA allocated is > 512Mb of RAM. It's a known problem and one we're looking at different > ways/options to resolve and working with upstream to do so and > reconsidering 64K pages in Fedora. We've traditionally gone that route > due to large enterprise systems and to be in sync with downstreams > like RHELSA and CentOS in that regard. > > Peter > _______________________________________________ > arm mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Pavel Holica
_______________________________________________ arm mailing list -- [email protected] To unsubscribe send an email to [email protected]
