On Thu 15-06-23 19:58:37, 贺中坤 wrote: > Hi michal, glad to hear from you. > > > I am not really deeply familiar with zram implementation nor usage but > > how is the above allocation going to be charged without __GFP_ACCOUNT in > > the gfp mask? > > Yes，zs_malloc() did not charge compressed memory, even if we add this gfp. > so we need to implement this function in this patchset. But this flag should be > used to enable this feature. Let me check I understand. This patch on its own doesn't really do anything. You need the zs_malloc support implemented in patch 3 for this to have any effect. Even with that in place the zs_malloc doesn't follow the __GFP_ACCOUNT scheme we use for allocation tracking. Correct? > > Also what exactly is going to happen for the swap backed by the zram > > device? Your memcg might be hitting the hard limit and therefore > > swapping out. Wouldn't zs_malloc fail very likely under that condition > > making the swap effectively unusable? > > This is the key point, as i said above, zs_malloc() did not charge > compressed memory, > so zs_malloc will not fail under that condition. if the zram swap is > large enough, zs_malloc > never fails unless system OOM. so memory.max will be invalidated. I do not think this is answering my question. Or maybe I just misunderstand. Let me try again. Say you have a memcg under hard limit pressure so any further charge is going to fail. How can you reasonably implement zram back swapout if the memory is charged? -- Michal Hocko SUSE Labs
