the common case is that max_mapped doesn't reach zero, so either ways
(mainline or -aa) it's the same (i.e. no special exit path).
> all, you seem to trigger OOM earlier through the short path exit in shrink,
> which is a obvious nono. I would state it wrong to fix the oom-killer for this
> case, because it should not be reached at all.
Correct. Incidentally swap or no swap doesn't make any difference on the
exit-path of shrink_cache in -aa (furthmore if swap is full or if everything is
unfreeable I stop wasting an huge amount of time on the swap_out path at the
first failure, this allows graceful oom handling or it would nearly deadlock
there trying tp swap unfreeable stuff at every max_mapped reached). In -aa
max_mapped doesn't influcence in any way the exit path of shrink_cache.
max_mapped only controls the swapout-frequency. See:
if (!page->mapping || page_count(page) > 1) {
spin_unlock(&pagecache_lock);
UnlockPage(page);
page_mapped:
if (--max_mapped < 0) {
spin_unlock(&pagemap_lru_lock);
shrink_dcache_memory(vm_scan_ratio, gfp_mask);
shrink_icache_memory(vm_scan_ratio, gfp_mask);
#ifdef CONFIG_QUOTA
shrink_dqcache_memory(vm_scan_ratio, gfp_mask);
#endif
if (!*failed_swapout)
*failed_swapout = !swap_out(classzone);
max_mapped = orig_max_mapped;
spin_lock(&pagemap_lru_lock);
}
continue;
}
So it should work just fine as far I can tell.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/