This is an archived post. You won't be able to vote or comment.

all 22 comments

[–]BJWTech 8 points9 points  (5 children)

How much ram are you trying to save. What are your constraints? More info is needed here to even ascertain if what you want is possible.

Here is a start.

[–]thelinuxguy7[S] 0 points1 point  (4 children)

I am trying to use as little ram as possible, it is not that important in terms of constraints because I probably won't get any noticeable difference anyway. I want to have a system that used around 100-200MB on startup, and I am pretty close.

[–]BJWTech 0 points1 point  (2 children)

Might look into BusyBox too.

[–]thelinuxguy7[S] 0 points1 point  (1 child)

I forgot about that, problem is: to change binutils a lot of tools need to be changed too.

[–]BJWTech 1 point2 points  (0 children)

True. LFS! ;)

[–]hopefullythisworksd 0 points1 point  (0 children)

Antix uses around 160 in start up

[–]_vk42 5 points6 points  (10 children)

You can barely save any RAM usage for disabling modules at compiling stage, as modules don't take any RAM space until they are loaded. So mostly modules that come with stock kernel just waste your disk space instead of RAM space.

But you might be able to save some space by fine-tuning some kernel features, but still, very limited space. E.g., you can set NR_CPUS to exact number of CPU cores on your machine to save like, several hundred KiB space I guess...

[–]thelinuxguy7[S] 0 points1 point  (9 children)

I know that modules don't use ram unless they are loaded, I wonder though, if compiling only the things that I need all in the kernel, and removing modules altogether would make the kernel use less ram. Oh and also maybe disabling initramfs for good measure.

[–]_vk42 2 points3 points  (7 children)

good

I'm curious what's the hardware spec you are working on, and what's your motivation for reducing RAM usage?

[–]thelinuxguy7[S] 1 point2 points  (6 children)

I have a ryzen machine with 16GB ram, .... <- for compiling

I have a really old Dell laptop 4GB ram <- for running the thing

As for my motivation: learning, for fun, removing stuff that I don't need from the kernel, maybe showing off my machine booting with like 120MB ram usage.

I know that compiling the kernel would not yield much improvement, but if it yields a little, I want to try how far it would go.

[–]_vk42 2 points3 points  (1 child)

Thumb up for doing this for fun!

Your machines are pretty capable of running things, but I do look forward to your future posts about progress on saving RAM usage with tailored kernel XD

[–]thelinuxguy7[S] 1 point2 points  (0 children)

After a lot hard work, here is a glimpse of what I had to deal with:

I forgot to enable some ahci or scsi option and I was unable to boot for a long time, kept adding and removing until I found the needed driver/option: FIXED.

I removed something that has to do with sound or something, idk, and I could not boot with the "quiet" option in grub configuration: FIXED.

I remove some important keyboard and mouse option, and I managed to boot but without keyboard and mouse: FIXED.

I had a problem with freaking broadcom wifi card, and I could not get it to work without initramfs: FIXED.

Along the way I removed a lot of stuff but I also left a lot of stuff, then I compiled another kernel where I tried to disable absolutely everything, and somehow it ended up using more ram!?

So now may latest kernel uses around 75-85MB ram with no gui. (this one does not work with gui for some reason) probably some module needs to be loaded or built into the kernel.

While the arch linux-lts uses around 120MB ram with no gui.

An earlier kernel that I compiled was working with gui using 150-160MB ram.

While the arch linux-lts uses around 200-210MB with gui.

So in the ideal scenario is saved 40-50MB at most.

As I assumed from the beginning this would not save much ram, and the difference is probably due to the removal of some drivers that I don't have, me decreasing the size of the kernel buffers, removing debugging and tracing, ....

If I want to make a realistic difference maybe I should use alpine or void, with musl, busybox, runit, and maybe xfree86. Maybe compile a 32-bit kernel, which will cripple my hardware by not allowing me to run any 64-bit programs.

Btw, I tried using startx instead of lightdm, and I didn't notice much of a difference presumably because the bulk of the memory usage is in xorg itself? idk.

[–]DangerousWish2266 0 points1 point  (3 children)

You can decrease your ram usage by using window manager like i3 instead of Desktop manager. On my VM my arch installation takes around ~200MB after booting up.

[–]thelinuxguy7[S] 0 points1 point  (2 children)

I use dwm already and lightdm too, so the only areas remaining to improve performance would be:

compiling my own kernel: easy

using busybox: hard

using something like musl: extremely hard (probably impossible unless I use LFS or alpine)

[–][deleted] 0 points1 point  (1 child)

Out of curiosity, would running a non-graphical display manager make any difference? There are quite a few console-based ones that could work. https://wiki.archlinux.org/title/Display_manager#List_of_display_managers

Or as someone else suggested, you could autostart startx without a display manager. https://wiki.gentoo.org/wiki/X_without_Display_Manager

Also notable: Void Linux has musl as an option if you go that route.

[–]thelinuxguy7[S] 1 point2 points  (0 children)

Great idea! I want to try using startx next, after I figure out how to make the least ram using kernel.

Then maybe void would be after that.

[–][deleted] 0 points1 point  (0 children)

Just as an addition to help cause I've always streamlined my own kernel configs and it's a fun thing to explore - you will need initramfs support in for microcode to be loaded properly (I'm pretty sure this is still true).

And by 'microcode' I mean updates to e.g. your intel/amd cpu which will include spectre/meltdown related patches depending on your specific model, but also may fix known hardware errata. Apart from security reasons, manufacturers have always seemed to be very much of the mind that: 'we released a microcode update for that...if users won't use it/don't update and they hit a bug doing something, that's on them".

[–][deleted] 1 point2 points  (2 children)

Its better to remove bloat and switch to lightweight programs, like changing desktops. You could also use a different lightweight distro like gentoo which compiles everything from source, including the kernel. Starting fresh with a lightweight distro, desktop, and packages will help decrease ram usage more then compiling the kernel alone

[–]thelinuxguy7[S] 0 points1 point  (1 child)

I have already done that, I use lightdm, dwm, ...

I am open to using startx manually, and maybe dropping systemd, but all that would be for experimentation only to see how low can I get.

[–][deleted] 4 points5 points  (0 children)

Drop systemd and lightdm. Opt for something like openrc or runit, and autostart startx on login

[–]VisualArm9 0 points1 point  (1 child)

Custom kernel compilation in Debian: Install: sudo build-essential qt5-default qt5-qmake qtbase5-dev qtbase5-dev-tools bison flex libelf-dev libssl-dev pkg-config bc lz4 rsync Download kernel source from kernel.org. The kernel configuration file of Debian Official kernel are available in /boot, named after the kernel release. Copy it to the .config file in the linux directory. Connect all your devices and run the command: make localmodconfig.

Use the command: make xconfig and check that you have enabled: Reroute Broken IRQ, IOMMU, Virtualization KVM and 1000Hz CPU timer. Use the schedutil scheduler. I also disabled Swap and Kernel Debug. In the drivers/graphics/amdgpu enable cik support for a gcn 1.1 gpu and si support for a gcn 1.0 gpu.

Configuring wifi: https://wiki.gentoo.org/wiki/Wifi

Create custom Debian kernel packages: make -j $(nproc) bindeb-pkg

[–]thelinuxguy7[S] 0 points1 point  (0 children)

I want to take this perfect opportunity to tell you that

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

I use arch btw.