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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
