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. Acked-by: Vladimir Davydov <vdavydov@xxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
