Ntpd config file support

[Mike Dean]

The key word is, "can," as in your statement, "can be read back in again."
 If it's designed to only ever be loaded the first time it's executed after
boot, then there will be no reason to load it back in again when executed
after that first time.  If there's no need for the code, it won't be read
back in again.  You would have to specifically request it to be loaded upon
subsequent executions in order for it to be read in again.

This is why the kernel *does* successfully reduce RAM consumption by code
when it unloads the initialization code.  It just requires proper design.
 It's not some sort of kernel black magic which requires ring 0 or special
hardware support.  It's just good design.


Mike Dean



On Thu, Mar 20, 2014 at 1:08 PM, Denys Vlasenko <vda.linux at googlemail.com>wrote:

> On Thu, Mar 20, 2014 at 6:47 PM, Mike Dean <mdean at emacinc.com> wrote:
> > Michael, Denys,
> >
> > I'm sorry; it seems you don't understand.  I wasn't referring to
> depending
> > on gcc to do the linking for you, but rather doing it yourselves.  I'm
> aware
> > that you guys are used to depending on compilers, linkers and the kernel
> to
> > do the hard work for you, but really, it's not that tough to do.
>  There's no
> > reason you would have to load init code just because the busybox process
> was
> > started.  You load that on demand, not by default.
>
> In fact I don't understand what "init code" you are talking about.
>
> > That way, you don't
> > waste memory by loading init code that has nothing to do with the task
> > busybox was launched to perform.
>
> The text pages  (pages contaning machine code) are read-only, and
> on MMU architectures they are shared.
>
> Meaning, in fact there is only one copy of each text page in RAM
> even if I run a thousand of busybox processes; and if there is
> memory pressure, kernel will find least used text pages
> and unmap them, freeing RAM for other use - because
> if they will be needed again, they can be read back
> from filesystem.
>
> IOW, for all intents and purposes RAM consumption by code
> can't be reduced by "unloading parts of code by hand" -
> kernel already does almost everything possible in that area.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140320/a63461ba/attachment-0001.html>