Re: [PATCH v2] mm: memory: move mem_cgroup_charge() into alloc_anon_folio()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2024/1/19 23:46, Michal Hocko wrote:
On Fri 19-01-24 20:59:22, Kefeng Wang wrote:
GFP_TRANSHUGE_LIGHT is more interesting though because those do not dive
into the direct reclaim at all. With the current code they will reclaim
charges to free up the space for the allocated THP page and that defeats
the light mode. I have a vague recollection of preparing a patch to

We are interesting to GFP_TRANSHUGE_LIGHT and _GFP_NORETRY as mentioned
above.

if mTHP can be smaller than COSTLY_ORDER then you are correct and
NORETRY makes a difference. Please mention that in the changelog as
well.


For memory cgroup charge, _GFP_NORETRY checked to make us directly skip
mem_cgroup_oom(), it has no concern with folio order or COSTLY_ORDER when
check _GFP_NORETRY in try_charge_memcg(), so I think NORETRY should
always make difference for all large order folio.

we do not OOM on COSTLY_ORDER (see mem_cgroup_oom). So NORETRY really
makes a difference for small orders.

I see what you mean, but we may describe the different processes, if
GFP_TRANSHUGE | __GFP_NORETRY returned from vma_thp_gfp_mask(),
then we never involved with mem_cgroup_oom(), since mem_cgroup_oom()
will be skipped in try_charge_memcg(), that is what I want to say,
and in this case, no oom for order < COSTLY_ORDER or order > COSTLY_ORDER. But if GFP is GFP_TRANHUGE, then we may enter mem_cgroup_oom(), and maybe oom if order < COSTLY_ORDER.

So Yes, NORETRY really makes a difference for small orders.





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux