Re: [PATCH -mm 0/2] mm: page_ext: split page_ext flags

Yafang Shao
2022-12-18T10:01:51Z

On Sun, Dec 18, 2022 at 4:08 PM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
>
> On Sat, Dec 17, 2022 at 10:58:31AM +0000, Yafang Shao wrote:
> > On 64bit system, page extension is for debugging purpose only currently,
> > because of its overhead, in particular the memory overhead.
> >
> > Once a page_ext is enabled, at least it will take 0.2% of the total
> > memory because of the page_ext flags, no matter this page_ext uses it or
> > not. Currently this page_ext flags is only used for page_owner on 64bit
> > system. So it doesn't make sense to allocate this flags for all page_ext
> > by default. We'd better move it into page_owner's structure, then when
> > someone wants to introduce a new page_ext which may be memory-overhead
> > sensitive, it will save this unneeded overhead.
>

Hi Hyeonggon,

> I'm still worried about the approach of using page_ext for BPF memory
> accounting.
>

This patchset is independent of BPF memory accounting. It is just an
improvement for the page_ext itself.

> Let's say we finally accepted the approach of using page_ext for BPF memory
> accounting, and if it's not enabled by default, you need to rebuild the kernel
> when you want to check BPF memory usage. (Or make everyone bear the overhead
> by enabling page_ext default for BPF memory accounting that one may not be interested)
>

The compile config can be enabled by default, but the static key is
disabled by default. That said, the user doesn't need to rebuild the
kernel. The user can pass a kernel parameter to enable or disable it.
But that doesn't mean I have made a final decision to use page_ext to
account for it. I will investigate if the dynamic page_ext can be
introduced or not first. If we can allocate page_ext dynamically
rather than allocate them at boot, the page_ext will be used in the
production environment rather than for debugging purposes only, that
will make it more useful.

> How the problem of accounting kfree_rcu() is going?
> Doesn't call_rcu() work for the problem?
> I still think it's much more feasible.
>

I'm also investigating the call_rcu() solution. The disadvantage of
call_rcu(), as I have explained in earlier replyment, is that it adds
restrictions for this solution and it can be broken easily if MM guys
introduce other deferred freeing functions inside mm/. That will be a
burden for further development.

--
Regards
Yafang