Re: [LSF/MM/BPF TOPIC] Restricting or migrating unmovable kernel allocations from slow tier

Byungchul Park
2025-02-10T07:17:52Z

On Mon, Feb 10, 2025 at 01:00:02AM -0500, Gregory Price wrote:
> On Mon, Feb 10, 2025 at 11:33:47AM +0900, Harry (Hyeonggon) Yoo wrote:
> >
> > Premise: Some ZONE_NORMAL capacity exists on CXL memory
> > due to its large capacity.
> >
> What you actually need to show to justify increasing the complexity is
> (at least - but not limited to)
>
> 1) structures you want to migrate are harmful when placed on slow memory
>
> ex) Is `struct page` on slow mem actually harmful? - no data?

Then we can hold this one until it turns out it's harmful or give up.

> ex) Are page tables on slow mem actually harmful? - known, yes.

Defenitly yes. What can be the next?

> 2) The structures cannot be made to take up less space on local tier
>
> ex) struct page can be shrunk - do that first
> ex) huge-pages can be deployed - do that first

I'm really courious about this. Is there any reason that we should work
these in a serialized manner?

> 3) the structures take up sufficient space that it matters
>
> ex) struct page after shrunk might not - do that first
> ex) page tables with multi-sized huge pages may not - do that first

Same. Should it be serialized?

> 4) Making the structures migratable actually does something useful
>
> are `struct page` or page tables after #2 and #3 both:
>
> a) going through hot/cold phases enough to warrant being tiered
>
> b) hot enough for long enough that migration matters?
>
> You can probably actually (maybe?) collect data on this today - but
> you still have to contend with #2 and #3.

Ah. You seem to mean those works should be serialized. Right? If it
should be for some reason, then it could be sensible.

Byungchul

> > I don't understand why we shouldn't introduce more kernel movable memory
> > if that turns out to be beneficial?
> >
>
> No one is going to stop research you want to do. I'm simply expressing
> that I think it's an ill-advised path to take.
>
> ~Gregory