Daemon ram usage

[Denys Vlasenko]

On Friday 02 May 2014 20:25, Laurent Bercot wrote:
> On 02/05/2014 13:30, Morten Kvistgaard wrote:
> > When I build “daemon” applets into Busybox, I’m wondering about the ram usage.
> > (...)
> > But when executing it, the ram usage seems to be [Busybox flash size + local ram allocations].
> >  Meaning that instead of 50k ram, it takes up 350k. Or so my top command reports. Is this true?
> 
>   Usually, the size reported by top and ps is virtual. It's the amount of virtual
> address space the binary uses; but in most cases, the real amount of memory
> the process is using is a lot smaller than that. The kernel uses physical
> memory page by page, so only the required amount of real memory (in your
> example, enough to read the "init" applet code and data) is actually used.

busybox top has the 's' mode where it shows lots of memory stats:

Mem total:2052016 anon:487668 map:80096 free:356896
 slab:82644 buf:71712 cache:1026828 dirty:108 write:0
Swap total:131068 free:131068
  PID   VSZ VSZRW^  RSS (SHR) DIRTY (SHR) STACK COMMAND
 2257  574m  524m  347m  2804  320m   128   216 /usr/app/firefox-3.6/firefox-bin
 2178  349m  341m 89880  1272 86372   128   128 X :0
 4315 92604 29688 80204 11588 39120     0  1856 kmail -caption KMail -icon kmail -miniicon kmail
 6696 54744 26964 16540 14844  7676  6616   132 kio_smtp [kdeinit] smtps /.local/tmp/ksocket-root/klauncheriyTBGb.slave-socket /.local/tmp/ksocket-root/kmailq9HPgb.slave-socket
 2248 32528  4072 22168 17272  9672  6464   132 kicker [kdeinit]
 2246 30372  4004 20240 16492  9496  6468   132 kdesktop [kdeinit]
 6756 30492  3216 19956 16892  9044  6492   132 konsole [kdeinit]
 2251 32652  2940 20448 15268  9916  6484   132 knotify [kdeinit]
 2244 28832  2896 18552 16132  8264  6484   132 kwin [kdeinit]

Pressing 's' again selects column to sort on, 'r' reters the sort.
I usually look at DIRTY column, it appears to me most meainingful.

>   However, Blackfin processors don't have a real MMU, so I don't think it
> applies to you. I wouldn't swear it, as I have no experience with noMMU
> systems, but I think that in your case, the whole binary gets loaded into
> memory, and is indeed using 350k.
> 
>   I'm not aware of solutions to this - except, maybe, that the Busybox approach
> of embedding everything into one binary is not suited to noMMU, and you'd be
> better off with a collection of small binaries, especially for long-lived
> programs.

We have libbusybox for that. Many nommu arches still can share code
if it is in a relocatable library (position-independednt code).

Select these options:

CONFIG_BUILD_LIBBUSYBOX=y
CONFIG_FEATURE_INDIVIDUAL=y
CONFIG_FEATURE_SHARED_BUSYBOX=y

and you will end up with one large file, libbusybox.so.1.23.0,
and 356 tiny (~2k) executables.

-- 
vda