Re: [BUG] staging: android: ashmem: Deadlock during ashmem_shrink

From: Shankar Brahadeeswaran
Date: Tue Apr 30 2013 - 09:29:55 EST

Hi Robert,
Thanks for the patch. In the first email in this thread I was
proposing the same solution and had asked whether doing this has any
side effects.
That is how this discussion started. I did some experiments and have
got the answers for that. Just for every ones benefit I've re-worded
the question again
and put the details of the experiment below.

On occasions when we return because of the lock unavailability, what
could be the worst case number of ashmem pages that are left
unfreed (lru_count). Will it be very huge and have side effects?

To get the answer for this question, I added some instrumentation code
to ashmem_shrink function on top of the patch. I ran Android monkey
tests with lot of memory hungry applications so as to hit the Low
Memory situation more frequently. After running this for almost a day
I did not see a situation where the shrinker did not have the mutex.
In fact what I found is that (in this use case at-least) most of the
time the "lru_count" is zero, which means the application has not
unpinned the pages. So the shrinker has no job to do (basically
shrink_slab does not call ashmem_shrinker second time). So worst case
if we hit a scenario where the shrinker is called I'm sure the
lru_count would be very low. So even if the shrinker returns without
freeing them (because of unavailability of the lock) its not going to
be costly.

After this experiment, I too think that this patch (returning from
ashmem_shrink if the lock is not available) is good enough and does
not seem to have any major side effects.

PS: Any plans of submitting this patch formally?

Warm Regards,
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at