How can it all fit?

Sixteen megabytes is a pitful amount of memory, and I sometimes have to remind myself of that. I have grown too accustomed to thinking of that in terms of a “workable” amount of space, and it’s not. Even by my standards, it’s far less than what is practical, usable or functional.

And yet these Awesome-based console-application systems are regularly using up less than half of the 12Mb htop says I have left to use, and there’s no sign of it demanding more space any time soon. What’s the story? How does it all fit in under 16Mb?

I don’t know. It’s got to be one of those Russian dolls things. Just in the way of explanation, here’s a “baseline” system, freshly booted and with nothing but two instances of urxvt running (and yes, that is how sparse a Crux system runs. If you want to avoid all those sputtering little do-nothings in your htop report, start using Crux. It returns your hardware to you).

A lowly 5Mb of memory consumed, plus a few more in swap. I should mention that my swappiness is set to 60, but I don’t know if that will really make much difference when there’s only 16Mb to work with in the first place.

Now let’s add a little to the workload. Here’s calcurse, which I mentioned a day ago as a fantastic replacement for the GTK-based Osmo, if you’re inclined to go console.

It hardly makes a dent. Memory consumption went from 5Mb to 6Mb, which means the space consumed by calcurse is probably less than a full megabyte. Even the swap space usage is the same. But that’s probably only to be expected, since calcurse is not exactly a intense or vivacious application. Unless you’re adding to it, there’s not a lot to expect of it. It could probably easily float along on a Commodore 64, with a few modifications.

Let’s up the ante. Here’s alpine, in the middle of a valid and live e-mail polling session. In other words, not fake e-mails to myself.

That’s more like it. Six megabytes consumed, and this time swap space has to give up two more megabytes to keep the system from imploding! Ha! Now we’re really eating up resources!

Maybe. That’s still only a grand total of 3Mb over what the freshly booted system needed, and unless alpine is actively sending or receiving e-mails, there’s not a lot it really does. Something that requires constant effort might show a real drain on memory. Here’s irssi.

Not as bad as I thought, even with irssi’s constant relay between me and Freenode. Only 6Mb live memory used, and up to 9Mb of swap needed, and that’s with both #archlinux and #crux open at the same time. I suppose if I really wanted smoke to come out of the floppy drive, I should have jumped into #ubuntu too. That place is a mess. 😯

After that though, I don’t know how much more I can tax this machine. Here’s snownews, which, like alpine, isn’t really very demanding so long as it’s not checking its feeds.

Not even twitching. And that swap space use, now, might even be cached programs that I already started. I don’t know, but I have a feeling looking at swap now isn’t much of an indicator of system demand.

Here’s Charm; Python might bog this down a bit. It’s a little slow to start (relatively speaking, of course), and that I blame on its Python underbelly. Prepare to be disappointed. …

At last, finally, I break the 7Mb mark. I still haven’t crested at two-thirds of the available memory, but at least now I can say I use more than half of the 12Mb I have on hand. And unused memory is wasted memory … or so the gurus say. Good thing I’m not a guru. 🙄

All right. I’m going for broke. I’m going to make this thing sweat if it’s the last thing I do. I shall force it to show a picture of itself, and in some sort of twisted backronymatic befuddlement, I will finally break 10Mb of usage. Here’s feh, displaying one of these screenshots on the host.

Survey says … no. No worse than anything else, really. It’s slow and I can blame that on the time it takes to scale down a photo to half its size, but it’s not exactly eating up my memory or causing rampant disk-swapping. I’m almost disappointed at this point.

Here’s mc, performing damage control, in a manner of speaking.

Still no singular chomp on my memory — that too seems to only take up a single megabyte. About the only thing I have left that might be a system demand is a browser, and I’m starting to worry that it won’t be very impressive. Here’s elinks, after signing into the Ubuntu Forums.

No luck there either. elinks tends to “hover” for a while, instead of opening pages very fast, but I wonder how much of that is elinks stripping out the visual garbage and stuffing it into /dev/null, and how much is just slow processor speed. The ‘forums are notoriously slow for me (it’s the design scheme), so elinks pausing for a second or two or three is only what I expect. (The Arch forums, by comparison, load exceptionally fast for me on a “normal” machine … well, on this machine too, I guess.)

But there’s not much of a drag on the system that I can blame on elinks. It might be slow, that might be the page, and it might be the processor. But it doesn’t seem to be anything I can say is because of low memory.

One last ace up my sleeve: cmatrix. This little monster has got to cause some sort of dent.

Bah. I give up. It’s taking up processor time, but not memory. The experiment is a failure, gentlemen. No one program is taking up much more than 1Mb at a time, and in that case there’s not much point in trying to find one program that will eat memory to a considerable degree.

I’ll go the opposite direction and open three or four at a time, and see what I get. Here’s snownews spawning elinks, with alpine, irssi and htop all running in their own rxvt-unicode instances. That will multiply the demands of rxvt-unicode several times over, and stack on a grand total of five applications. This should be good.

Well, I suppose that’s an “improvement,” in one way. Seventeen megabytes of swap consumed is definitely a high mark, but standing memory is still only requiring 7Mb. Since this is running freely and without paging, I can only assume that the bulk of what’s needed to do this can be done without disk access.

I suppose there’s something to be learned in this: That even if I dive into the guts of this machine, find the other memory bracket, install the 32Mb chip and successfully reassemble the thing, it might not lead to much of anything at all. As it stands now a running, active system doesn’t seem to need more than the 12Mb I have available, with a bit of swap space as insurance.

And going straight to console might speed things up a little bit because it takes less effort to display these applications in the native video environment, instead of under X. But the run speed isn’t going to improve drastically if I’m not ever paging out to the drive as a consequence of normal use.

The moral of the story: I have a lot to learn. But I knew that three years ago, when I put an Ubuntu CD in the drive and restarted my laptop. You just never stop being a newb.

21 thoughts on “How can it all fit?

  1. Duncan Snowden

    16Mb? That’s half what I had in my last Amiga, and it had a fair chunk of its OS in ROM. Congratulations, I think. 🙂

    “And going straight to console might speed things up a little bit because it takes less effort to display these applications in the native video environment, instead of under X.”

    Just what I was thinking. Since the only thing you have that really “uses” X is feh (and I think it’ll work with the framebuffer), wouldn’t GNU Screen be a better bet than Awesome?

    Reply
  2. Luca

    Hmm, have if its swapping too much have you tried playing with /proc/vm/swappiness? On the first image you have 7mb cached in memory, yet 8mb in swap. If the swappiness was decreased I’m sure more of this would be kept in memory.

    Reply
  3. You'll love this 2 little wm for the console :)

    Hi, when I read this article I was thinking that you would love to probe this 2 little wm:

    Viper Window Manager: http://vwm.sourceforge.net/screenshots.html
    a lightweight, extensible window manager for the console.

    dynamic virtual terminal manager: http://www.brain-dump.org/projects/dvtm/

    A Tiling window management for the console. dvtm brings the concept of tiling window management, popularized by X11-window managers like dwm to the console. As a console window manager it tries to make it easy to work with multiple console based programs like vim (nano), mutt (alpine), cmus or irssi. 😉

    I’d tried dvtm and is wonderful, a joy to use on really old hardware 😀

    If you like them, I known you’ll post about them 😛

    Reply
  4. Mark

    The basic install of RISC OS (which includes the desktop environment, a text editor, a raster graphics editor, a vector graphics editor, a calculator and a scorewriter) still comes on 4 Megabyte flash ROMs (AFAIK). Of course, a full ROS environment weighs in at 500 MBs, but you could probably run it in 16 MBs. ROS programs come from a time when every bit counted and are generally written with that goal in mind

    Reply
  5. colonelcrayon

    That’s the most awesome thing I’ve seen in a while. Congrats!

    I don’t think I’ll be able to rival those stats, simply because I have 1 GB of RAM and I don’t bother with swap space. I might try to bring my SliTaz system down below 30 MB of RAM though…

    Reply
  6. Mads

    I’d like to point out that the JEOS (virtual machine) install of commandline ubuntu is taking 16 MB of RAM per default, so it’s not completely unobtainable to run it in such specs.

    /Mads

    Reply
  7. K.Mandla Post author

    Thanks for the suggestions. I’ll look into JEOS and RISC OS for sure, as well as some of the alternative window managers.

    Reply
  8. colonelcrayon

    A few questions for the master:

    1. Did you do anything special with X? Even Xvesa can’t touch that on my system…

    2. Since it’s CRUX, we know you compiled a custom kernel. How zealous were you in pruning it?

    3. Could you post the RAM use (from htop) without X running?

    Reply
    1. K.Mandla Post author

      colonelcrayon: 1. No, and that’s part of the mystery. That’s the default, plain-jane Xorg 7.3 from the Crux i586 2.4 CD, with the Chips driver and nothing else. I haven’t even bothered to update the software on the machine.

      2. Extremely zealous. Dangerously zealous. Unethically zealous. No, really: If I had the least bit of doubt about whether or not something was “critical,” I threw it out. You’d be surprised at how many attempts it took to get a kernel I liked. But I can tell you this is probably the lightest, fastest one I have. Compiling it takes less than 12 minutes at 1Ghz. …

      3. A freshly booted system shows 3Mb of 12Mb used, and 0Mb swap usage. That’s with only six tasks running — htop itself, init, udevd, bash, agetty and dhcpcd.

      Reply
  9. Mads

    K.Mandla, in the spirit of open source, mind sharing the config file you use, so we can see how the “perfect” kernel is set up?

    /Mads

    Reply
  10. Pingback: Since you asked « Motho ke motho ka botho

  11. K.Mandla Post author

    Hold on to your hat. …

    Section "ServerLayout"
    	Identifier     "X.org Configured"
    	Screen      0  "Screen0" 0 0
    	InputDevice    "Mouse0" "CorePointer"
    	InputDevice    "Keyboard0" "CoreKeyboard"
    	Option		"AllowEmptyInput" "false"
    EndSection
    
    Section "Files"
    	RgbPath      "/usr/share/X11/rgb"
    	ModulePath   "/usr/lib/xorg/modules"
    	FontPath     "/usr/lib/X11/fonts/misc/"
    	FontPath     "/usr/lib/X11/fonts/TTF/"
    	FontPath     "/usr/lib/X11/fonts/OTF"
    	FontPath     "/usr/lib/X11/fonts/Type1/"
    	FontPath     "/usr/lib/X11/fonts/100dpi/"
    	FontPath     "/usr/lib/X11/fonts/75dpi/"
    EndSection
    
    Section "Module"
    	Load  "glx"
    	Load  "extmod"
    	Load  "xtrap"
    	Load  "record"
    	Load  "GLcore"
    	Load  "dbe"
    	Load  "dri"
    	Load  "freetype"
    	Load  "type1"
    EndSection
    
    Section "InputDevice"
    	Identifier  "Keyboard0"
    	Driver      "kbd"
    	Option		"CoreKeyboard"
    	Option		"XkbRules" "xorg"
    	Option		"XkbModel" "jp106"
    	Option		"XkbLayout" "jp"
    	Option		"XkbVariant" ""
    EndSection
    
    Section "InputDevice"
    	Identifier  "Mouse0"
    	Driver      "mouse"
    	Option	    "Protocol" "auto"
    	Option	    "Device" "/dev/input/mice"
    	Option	    "ZAxisMapping" "4 5 6 7"
    	Option		"MinSpeed" "0.75"
    EndSection
    
    Section "Monitor"
    	Identifier   "Monitor0"
    	VendorName   "Monitor Vendor"
    	ModelName    "Monitor Model"
    EndSection
    
    Section "Device"
            ### Available Driver options are:-
            ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
            ### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
            ### [arg]: arg optional
            #Option     "Linear"             	# [<bool>]
            #Option     "NoAccel"            	# [<bool>]
            #Option     "HWclocks"           	# [<bool>]
            #Option     "SWcursor"           	# [<bool>]
            #Option     "HWcursor"           	# [<bool>]
            #Option     "STN"                	# [<bool>]
            #Option     "UseModeline"        	# [<bool>]
            #Option     "Stretch"            	# [<bool>]
            #Option     "LcdCenter"          	# [<bool>]
            #Option     "MMIO"               	# [<bool>]
            #Option     "SuspendHack"        	# [<bool>]
            #Option     "FixPanelSize"       	# [<bool>]
            #Option     "18BitBus"           	# [<bool>]
            #Option     "ShowCache"          	# [<bool>]
            #Option     "ShadowFB"           	# [<bool>]
            #Option     "Rotate"             	# [<str>]
            #Option     "SetMclk"            	# <freq>
            #Option     "FPClock8"           	# <freq>
            #Option     "FPClock16"          	# <freq>
            #Option     "FPClock24"          	# <freq>
            #Option     "FPMode"             	# [<bool>]
    	Identifier  "Card0"
    	Driver      "chips"
    	VendorName  "Chips and Technologies"
    	BoardName   "F65548"
    	BusID       "PCI:0:20:0"
    EndSection
    
    Section "Screen"
    	Identifier "Screen0"
    	Device     "Card0"
    	Monitor    "Monitor0"
    	DefaultDepth	16
    	SubSection "Display"
    		Viewport   0 0
    		Depth     1
    	EndSubSection
    	SubSection "Display"
    		Viewport   0 0
    		Depth     4
    	EndSubSection
    	SubSection "Display"
    		Viewport   0 0
    		Depth     8
    	EndSubSection
    	SubSection "Display"
    		Viewport   0 0
    		Depth     15
    	EndSubSection
    	SubSection "Display"
    		Viewport   0 0
    		Depth     16
    		Modes		"800x600" "640x480"
    	EndSubSection
    	SubSection "Display"
    		Viewport   0 0
    		Depth     24
    	EndSubSection
    EndSection
    
    
    Reply
  12. Pingback: An apology, and an update « Motho ke motho ka botho

  13. Pingback: Putting the Pentium back to work « Motho ke motho ka botho

  14. Pingback: Looking close at memory usage « Motho ke motho ka botho

  15. Kyle

    Been reading your blog. Some pretty neat stuff.

    What you’re seeing has to do with overcommiting memory.

    See, most C programs request more memory than they actually need, so the kernel plays along and hands out more memory than it really has.

    There’s a lot of technical explanations of this, but basically, most processes ask for far more than they need. Think of a kid at an all-you-can-eat buffet: If unchecked, kids will pile several plates full of mashed potatoes and mac & cheese, eat a few mouthfulls of it, then leave behind enough food to feed a family of four. The kernel knows this about it’s kids (processes), so it pretends to give them _everything_ they ask for, knowing that there’s no way that python is going to finish that mountain of gloopy chocolate pudding(memory) it just asked for.

    Lookup sysctl vm.overcommit_memory and vm.overcommit_ratio for info on how to tune this behavior, or for a more technically sound explanation.

    Reply
  16. Pingback: vm.overcommit_memory and _ratio « Motho ke motho ka botho

Leave a comment