On Wed, 17 Oct 2012, Dave Jones wrote:
> > Sounds good. Is it possible to verify that policy_cache isn't getting
> > larger than normal in /proc/slabinfo, i.e. when all processes with a
> > task mempolicy or shared vma policy have exited, are there still a
> > significant number of active objects?
>
> Killing the fuzzer caused it to drop dramatically.
>
> Before:
> (15:29:59:davej@bitcrush:trinity[master])$ sudo cat /proc/slabinfo | grep policy
> shared_policy_node 2931 2967 376 43 4 : tunables 0 0 0 : slabdata 69 69 0
> numa_policy 2971 6545 464 35 4 : tunables 0 0 0 : slabdata 187 187 0
>
> After:
> (15:30:16:davej@bitcrush:trinity[master])$ sudo cat /proc/slabinfo | grep policy
> shared_policy_node 0 215 376 43 4 : tunables 0 0 0 : slabdata 5 5 0
> numa_policy 15 175 464 35 4 : tunables 0 0 0 : slabdata 5 5 0
>
Excellent, thanks. This shows that the refcounting is working properly
and we're not leaking any references as a result of this change causing
the mempolicies to never be freed. ("numa_policy" turns out to be
policy_cache in the code, so thanks for checking both of them.)
Could I add your tested-by?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>