If you have basic GNU tools ( sh , grep , yes and head ) you can do this:

yes | tr \

x | head -c $BYTES | grep n # Protip: use `head -c $((1024*1024*2))` to calculate 2MB easily

This works because grep loads the entire line of data in RAM (I learned this in a rather unfortunate way when grepping a disk image). The line, generated by yes , replacing newlines, will be infinitely long, but is limited by head to $BYTES bytes, thus grep will load $BYTES in memory. Grep itself uses like 100-200KB for me, you might need to subtract that for a more precise amount.

If you want to also add a time constraint, this can be done quite easily in bash (will not work in sh ):

cat <(yes | tr \

x | head -c $BYTES) <(sleep $NumberOfSeconds) | grep n

The <(command) thing seems to be little known but is often extremely useful, more info on it here: http://tldp.org/LDP/abs/html/process-sub.html

Then for the use of cat : cat will wait for inputs to complete until exiting, and by keeping one of the pipes open, it will keep grep alive.

If you have pv and want to slowly increase RAM use:

yes | tr \

x | head -c $BYTES | pv -L $BYTESPERSEC | grep n

For example:

yes | tr \

x | head -c $((1024*1024*1024)) | pv -L $((1024*1024)) | grep n

Will use up to a gigabyte at a rate of 1MB per second. As an added bonus, pv will show you the current rate of use and the total use so far. Of course this can also be done with previous variants:

yes | tr \

x | head -c $BYTES | pv | grep n

Just inserting the | pv | part will show you the current status (throughput and total, by default, I think - otherwise see the man(ual) page).

Why another answer? The accepted answer recommends installing a package (I bet there's a release for every chipset without needing a package manager); the top voted answer recommends compiling a C program (I did not have a compiler or toolchain installed to compile for your target platform); the second top voted answer recommends running the application in a VM (yeah let me just dd this phone's internal sdcard over usb or something and create a virtualbox image); the third suggests modifying something in the boot sequence which does not fill the RAM as desired; the fourth only works in so far as the /dev/shm mountpoint (1) exists and (2) is large (remounting needs root); the fifth combines many of the above without sample code; the sixth is a great answer but I did not see this answer before coming up with my own approach, so I thought I'd add my own, also because it's shorter to remember or type over if you don't see that the memblob line is actually the crux of the matter; the seventh again does not answer the question (uses ulimit to limit a process instead); the eighth tries to get you to install python; the ninth thinks we're all very uncreative and finally the tenth wrote his own C++ program which causes the same issue as the top voted answer.