On Mon 16-07-18 17:45:06, Yafang Shao wrote: > On Mon, Jul 16, 2018 at 3:58 PM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > On Sat 14-07-18 16:32:02, Yafang Shao wrote: > >> try_charge maybe executed in packet receive path, which is in interrupt > >> context. > >> In this situation, the 'current' is the interrupted task, which may has > >> no relation to the rx softirq, So it is nonsense to use 'current'. > >> > >> Avoid bothering the interrupted if page_counter_try_charge failes. > > > > I agree with Shakeel that this changelog asks for more information about > > "why it matters". Small inconsistencies should be tolerable because the > > state we rely on is so rarely set that it shouldn't make a visible > > difference in practice. > > > > HI Michal, > > No, it can make a visible difference in pratice. > The difference is in __sk_mem_raise_allocated(). > > Without this patch, if the random interrupted task is oom victim or > fatal signal pending or exiting, the charge will success anyway. That > means the cgroup limit doesn't work in this situation. > > With this patch, in the same situation the charged memory will be > uncharged as it hits the memcg limit. > > That is okay if the memcg of the interrupted task is same with the > sk->sk_memcg, but it may not okay if they are difference. > > I'm trying to prove it, but seems it's very hard to produce this issue. So it is possible that this is so marginal that it doesn't make any _practical_ impact after all. -- Michal Hocko SUSE Labs -- 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
