On Sat, 31 May 2014, Vladimir Davydov wrote: > ... which means more async workers, more complication to kmemcg code :-( > > Sorry, but I just don't get why we can't make kmem_cache_shrink never > fail? Is failing de-fragmentation, which is even not implied by the > function declaration, so critical that should be noted? If so, we can > return an error while still shrinking empty slabs... There could be other reasons for failure in the future as kmem_cache_shrink is updated. Requiring kmem_cache_shrink to never fail may cause problems for future modifications. > If you just don't like the code after the patch, here is another, less > intrusive version doing practically the same. Would it be better? That looks acceptable. Acked-by: Christoph Lameter <cl@xxxxxxxxx> -- 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>