[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZKvi4ZvhQaIFtSvg@dhcp22.suse.cz>
Date: Mon, 10 Jul 2023 12:52:17 +0200
From: Michal Hocko <mhocko@...e.com>
To: Zhongkun He <hezhongkun.hzk@...edance.com>
Cc: minchan@...nel.org, senozhatsky@...omium.org, david@...hat.com,
yosryahmed@...gle.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 2/2] zram: charge the compressed RAM to the page's
memcgroup
On Fri 07-07-23 12:47:07, Zhongkun He wrote:
[...]
> @@ -1692,11 +1725,21 @@ static int zram_recompress(struct zram *zram, u32 index, struct page *page,
>
> zs_unmap_object(zram->mem_pool, handle_new);
>
> + /*
> + * Recompress will reclaim some memory, so we set the reclaim
> + * flag in order to charge comp_len_new successfully.
> + */
> + noreclaim_flag = memalloc_noreclaim_save();
> + objcg = zram_get_obj_cgroup(zram, index);
> + obj_cgroup_get(objcg);
> zram_free_page(zram, index);
> + obj_cgroup_charge_zram(objcg, GFP_KERNEL, comp_len_new);
AFAICS your obj_cgroup_charge_zram doesn't have gfp argument.
Anyway, memalloc_noreclaim_save is an abuse IMHO (the primary purpose of
the flag is to prevent recursion into the memory reclaim). Do you really
can not perform any memory recalim to trigger to free up some memory if
the memcg is at the hard limit boundary?
> + zram_set_obj_cgroup(zram, index, objcg);
> zram_set_handle(zram, index, handle_new);
> zram_set_obj_size(zram, index, comp_len_new);
> zram_set_priority(zram, index, prio);
>
> + memalloc_noreclaim_restore(noreclaim_flag);
> atomic64_add(comp_len_new, &zram->stats.compr_data_size);
> atomic64_inc(&zram->stats.pages_stored);
>
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists