inotifyd - possible memory leak?
Denys Vlasenko
vda.linux at googlemail.com
Sat Nov 28 16:44:42 UTC 2009
On Saturday 28 November 2009 15:34, Piotr Grudzinski wrote:
> >Static busybox is not recommended for NOMMU systems.
> >
> >On NOMMU, code page sharing in two different processes
> >is not possible. Therefore on your system every new copy
> >of busybox needs a new ~250k chunk for ALL its code,
> >even the one which will never be used by the applet you run.
> >
> >I heard that people deal with it by selecting just one applet
> >and building busybox, repeating the process for each applet.
> >
> >They end up with separate binaries for each applet.
> >
> >I would guess it still makes sense to group smallest
> >applets (in your case, for example: cat clear env
> >false hostname length mesg pwd sleep sync true usleep yes)
> >into a "combined" executable in order to reuse libbb code,
> >but large ones need to be separate.
> >
> >This is still inefficient, since libbb is not shared.
> >
> >Better solution is to switch off CONFIG_STATIC
> >and switch on CONFIG_BUILD_LIBBUSYBOX and CONFIG_FEATURE_INDIVIDUAL
> >(run "make menuconfig" and read their help text!).
> >
> >This way, you will have entire busybox as shared
> >library libbusybox.so.1.x.x, and many tiny binaries,
> >one per applet, every one contains just a call
> >to <applet>_main().
> >
> >But this requires your build system to be able to produce
> >dynamically build binaries and libraries.
> >
> >--
> >vda
>
> Even if I succeed with dynamically linked busybox on my NOMMU system
> will this solve the problem with memory fragmentation when -hush- shell is
> used?
Fragmentation can't be totally excluded. it can be reduced
by writing code specifically to reduce it, and also it is less likely
to actually cause problems when you have more of the free memory.
Also it helps when you reduce the size of your contiguoug memory
requests, like 256 Kb one you do when you load static busybox.
> Is the memory fragmentation justified for -hush- when -msh- seems to avoid
> it?
msh does not avoid fragmentation, it just doesn't produce as much of it.
I would happily take patches which either fix msh (it is VERY buggy)
or make hush better wrt fragmentation.
> Why would the -free- command show memory going down if the only problem
> is memory fragmentation?
Because Linux caches filesystem data:
# free
total used free shared buffers
Mem: 2054808 2030316 24492 0 114280
Swap: 131064 0 131064
Total: 2185872 2030316 155556
This is on my 2 GB machine. I assure you I do *not* have nearly 2 GB
of programs loaded at this moment. Most of it is filesystem cache:
shadow:~# echo 1 >/proc/sys/vm/drop_caches
shadow:~# free
total used free shared buffers
Mem: 2054808 353896 1700912 0 7564
Swap: 131064 0 131064
Total: 2185872 353896 1831976
--
vda
More information about the busybox
mailing list