Have you run your tests on the stock platform (even just the emulator) to
see if you are getting the behavior you expect there? There are a *lot* of
potential gotchas if trying to test this behavior: running at the right
oom_adj, fuzziness in the definition of "free memory", etc. I would suggest
We are trying to test Android LowMemoryKiller Driver using a sample
test application.
/sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15
MINFREE module parameter is set from the application.
echo 1536,2048,4096,5120,5632,6144 >/sys/module/lowmemorykiller/
parameters/minfree
The test appli
None of those oom_adj levels are going to do you any good, since those are
all considered critical or nearly critical processes. Please look at the
oom_adj levels that are defined in init.rc right around where the memory
thresholds are which provides the binning for the different memory levels.
O
(1) We are three launching processes which seek large chunks of memory from
the system.
- Our application from init.rc (oom_adj = -16), later changed to 13, cpu
consumtion 7%
- Test application (memoryeater) from shell (oom_adj = 0) , later changed
to 12
- Android Calculator application (oom_adj
What oom_adj is your test app running under?
On Wed, Nov 17, 2010 at 9:39 PM, Raja Pavan wrote:
> We are testing the lowmemorykiller.c driver of android, using a sample
> test application that malloc() and memset() memory. [code pasted
> below]
>
> void loopmalloc()
> {
>int size,i=0;
>f
We are testing the lowmemorykiller.c driver of android, using a sample
test application that malloc() and memset() memory. [code pasted
below]
void loopmalloc()
{
int size,i=0;
float **ptr = NULL;
printf("\n\nLoopMalloc starts\n\n");
ptr = (float **)malloc(200*sizeof(float
