Parag Warudkar wrote:
On Tue, Aug 26, 2008 at 8:53 PM, Greg Ungerer <gerg@xxxxxxxxxxxx> wrote:
I have some simple devices (network access/routers) with 8MB of RAM,
at power up not really being configured to do anything running 25
processes. (Heck there is over 10 kernel processes running!). Configure
some interfaces and services and that will easily push past 40.
I'd be happy with a 160k saving :-)
So you really need to run all 25 processes on that 8Mb box?
Yes, of course. Considerable effort has been put into running
a minimal set of processes (that still for fills the required function
set of this device).
(For reference even the NGW100 development board comes with 16Mb RAM).
Lots of development boards are fitted with lots of RAM.
And the pressure will still be on in _real_ products to reduce
the RAM footprint as much as possible. There are exceptions but
generally less is cheaper. Simple economics really.
Even if you do need those all 25 processes on the 8Mb box, fixing the
memory usage of those user space hogs is lot better than trying to
save 160Kb in kernel stacks.
Yep, been done too. You don't squeeze a lot into these smaller
devices without looking at everything in it.
Last I looked, user space wasn't particularly frugal with memory usage.
Then you haven't looked in the right places :-)
There are plenty of choices for making things small in user space.
Simple stuff like using uClibc, busybox, etc.
In this specific example things like /bin/init is 10k, /bin/inetd
is 10k, /bin/crond is 11k, etc. (Ofcourse it is a shared uClibc setup,
uClibc is ~300k). And XIP can help out here too.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@xxxxxxxxxxxx
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
