On Mon 23-05-16 13:37:58, Vladimir Davydov wrote: > On Thu, May 19, 2016 at 09:44:53AM +0800, Li RongQing wrote: > > On Wed, May 18, 2016 at 3:32 PM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > count should always be smaller than memsw.limit (this is a hard limit). > > > Even if we have some temporary breach then the code should work as > > > expected because margin is initialized to 0 and memsw.limit >= limit. > > > > is it possible for this case? for example > > > > memory count is 500, memory limit is 600; the margin is set to 100 firstly, > > then check memory+swap limit, its count(1100) is bigger than its limit(1000), > > then the margin 100 is returned wrongly. > > I guess it is possible, because try_charge forces charging __GFP_NOFAIL > allocations, which may result in memsw.limit excess. If we are below > memory.limit and there's nothing to reclaim to reduce memsw.usage, we > might end up looping in try_charge forever. I've never seen that happen > in practice, but I still think the patch is worth applying. You are right. I have completely missed a potential interaction with __GFP_NOFAIL. We even do not seem to trigger the memcg OOM killer for these requests to sort the situation out. Can we have updated patch with all this useful information in the changelog, please? Thanks Vladimir! -- Michal Hocko SUSE Labs -- 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>