[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZIsBM06ZJSbB+bXz@dhcp22.suse.cz>
Date: Thu, 15 Jun 2023 14:16:51 +0200
From: Michal Hocko <mhocko@...e.com>
To: 贺中坤 <hezhongkun.hzk@...edance.com>
Cc: minchan@...nel.org, senozhatsky@...omium.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [External] Re: [RFC PATCH 1/3] zram: charge the compressed RAM
to the page's memcgroup
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
Powered by blists - more mailing lists