ARM memory footprint
John Passaniti
would be running embedded Linux on an ARM9-class processor (yes, that
has a MMU, so it's not the MMU-less uClinux). The system would have
roughly 64 megabytes of RAM.
What I'm hoping someone here can give me is an indication of the
quiescent memory footprint of just Node.js targeting that platform.
That would be the size of the standard binary with any debugging
information stripped, and how much RAM Node and V8 gobble before any
application code is loaded. In other words, I want to get the base
memory "cost" of Node.js on such a platform.
The application that I am looking at using Node.js for would typically
involve UDP-based communications with a handful of embedded systems
while simultaneously managing a web-based GUI. So in this
application, we're not talking about a large number of concurrent
connections. Obviously the only way to know for sure what the run-
time cost of the application code and supporting in-memory data
structures will be is to code it and measure it. But before I run
down a road that may lead to nowhere, I am hoping that someone can
find some useful way to express how much memory I can expect to be
chewed up while Node.js is running code. I'm just looking for some
kind of gross measure that will tell me if Node.js (and V8) even makes
sense. Knowing that, I can either dive deeper or run away screaming.
Any information those who have worked with bringing Node.js to
embedded Linux on ARM is much appreciated.
Ben Noordhuis
It should be possible to run with only 64 MB but you will have to
tweak Node and/or your kernel. The issue I ran into (recently
actually) is that V8 tries to map a lot of virtual memory (like
hundreds of MBs) and will fail hard if your kernel doesn't like to
overcommit.
Dominic Tarr
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
Curtis Schofield
rad project
AJ ONeal
AJ ONeal
Ben Combee
> V8 VM is SLOW to load.
> Both reading files from NAND and compiling them to assembly before use can
> take seconds. Not good for an instant-on device.
Yeah, on webOS, we use a fork-server version of node.js for starting
new services without the overhead of getting a new V8 instance running
to reduce startup time.
Liam
Also, NAND is slow -- isn't NAND typically faster than disk seek/read?
Ben Combee
>> new services without the overhead of getting a new V8 instance running
>> to reduce startup time.
>
> A "fork-server" version? Can you elaborate?
Basically, there's a node.js process running waiting for a connection
with parameters to start a service. When that comes in, we have an
extension that lets it call the system call fork() to start a new
process that has a copy-on-write duplication of the V8 context. I
don't think we've released our patches.
> Also, NAND is slow -- isn't NAND typically faster than disk seek/read?
It's faster to seek, but NAND memory often is directly off the CPU
memory bus which means the processor is completely occupied when
reading blocks of Flash into RAM. A system like the TouchPad actually
uses eMMC memory that looks like a block filesystem and benefits from
the ability to do DMA through a controller to copy from flash into
memory without blocking the CPU.
Liam
> >> Yeah, on webOS, we use a fork-server version of node.js for starting
> >> new services without the overhead of getting a new V8 instance running
> >> to reduce startup time.
>
> > A "fork-server" version? Can you elaborate?
>
> Basically, there's a node.js process running waiting for a connection
> with parameters to start a service. When that comes in, we have an
> extension that lets it call the system call fork() to start a new
> process that has a copy-on-write duplication of the V8 context. I
> don't think we've released our patches.
configuration of Node...?
> > Also, NAND is slow -- isn't NAND typically faster than disk seek/read?
>
> It's faster to seek, but NAND memory often is directly off the CPU
> memory bus which means the processor is completely occupied when
> reading blocks of Flash into RAM. A system like the TouchPad actually
> uses eMMC memory that looks like a block filesystem and benefits from
> the ability to do DMA through a controller to copy from flash into
> memory without blocking the CPU.
isn't "raw" NAND usually managed by a dedicated controller?)
Ben Combee
> isn't "raw" NAND usually managed by a dedicated controller?)
True -- my raw NAND experience was a few years ago on the Palm Foleo
which had a CPU-managed NAND chip running either YAFFS or JFFS
depending on the time of the project. That's where I personally saw
really slow NAND performance, I've not seen it as much with the
eMMC-based devices.
