Re: [RFC PATCH v11 0/4] mm/swap: priority-based swap tiers with per-cgroup selection

[Youngjun Park]

Hi Lian!

> zram integration test, not yet a real multi-SSD performance test.
>
> One result seems relevant to this discussion: with a restricted parent
> and an unconfigured child, the child could still use the faster tier. I

I intentionally left out the parent/child hierarchy handling in this
version, since I thought it would be needed only at memcg integration
time. At this point, though, I think it is better to keep the
hierarchy even in the debugfs interface, 
so after reconsideration. I'll do that in v12!

> therefore agree that an inheritable memory.swap.prio.max looks like the
> cleaner first cgroup interface. A hole in the mask worked mechanically,
> but I do not yet have a convincing hierarchical use case for it; it felt
> more like per-cgroup swap-pool membership.

I plan to proceed with v12 as Johannes suggested. (I've replied
with my thoughts in the thread.)

> For the queue integration, one possible boundary is for the tier to own
> the queue/reader and for the swap queue to become the default per-tier
> device allocation policy. I would like to align this with both of you
> before changing v2. I will also continue the real multi-SSD tests.

I'd like to hear what Kairui and Chris think as well. If they agree,
this is the direction I prefer. Honestly, beyond preference, I think
it is the right one :) instead of allocating a separate swap queue
structure, the swap tier itself can be used for it!

> If either of you has suggestions or specific test cases you would like
> to see, please let me know. I have a few test setups available and should
> be able to try some of them. I am still getting up to speed on this part
> of MM, so please correct me if I missed some context or got any detail
> wrong.

When I send v12, I'll spell out more clearly the parts where we can
collaborate and what I'd like to propose to you. If anything comes up
before then, I'll reply on the v2 thread.

Thanks,
Youngjun