Re: 2.2/2.4/2.6 VMs: do malloc() ever return NULL?
From: Ihar 'Philips' Filipau
Date: Wed Nov 26 2003 - 09:41:20 EST
Richard B. Johnson wrote:
Here is a dynamic allocation scheme that doesn't fail with
the usual, i.e., less that 1/2 megabyte temporary storage. It
also automatically frees the RAM it's allocated.
int function(void *what, size_t len)
You want to say that space is always allocated?
And how can you make graceful error handling if there is no memory left?
malloc() has return value, mlock() has return value. So there is at
least room for error handling. But in your case if you will by mistake
will run second instance of application - what will happend? I suppose
crash or welcome oom_killer. Both not nice.
If you need really large buffers and have only a single
thread, you can still allocate memory at compile-time, i.e.,
I was thinking about this - it has a lot of adavantages and one very
big disadvantage: you need to recompile app to scale system, you cannot
make this a command line/configuration parameter.
Embedded? with swap?!?
What you have smoken?! - take me to your dealer!-)))
Absolutely. A RAM-Disk on non-paged RAM. It allows individual
tasks to keep track of a valuable resource with minimum
overhead. It would be nicer if there was a "get free pages"
function call but you can make a driver for a virtual device
that returns such information. Then you don't need the
RAM disk to keep track of virtual memory
A-ha. A la mtd/rw flash.
Let's say: I'm working on embedded system - but it is less embedded
than other embedded systems ;-)
Thanks for your advices in any way - probably something can be used
Ihar 'Philips' Filipau / with best regards from Saarbruecken.
-- _ _ _
Because the kernel depends on it existing. "init" |_|*|_|
literally _is_ special from a kernel standpoint, |_|_|*|
because its' the "reaper of zombies" (and, may I add, |*|*|*|
that would be a great name for a rock band).
-- Linus Torvalds
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/