Re: [PATCH RFC] mm: ghost swapfile support for zswap

[Chris Li <chrisl@kernel.org>]

On Mon, Dec 1, 2025 at 8:43 PM Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> For the benefit of anybody following this from the sidelines, the
> third zswap maintainer also expressed concerns about Chris's proposal
> upthread. He works for the same company as Chris.

Yes, I don't know who's interest Yosry's represent. We have a
disagreement on the swap abstraction 2023 that is why I have an
alternative proposal. The community back then strongly favored my
proposal. I guess Yosry just hasn't graduated from that yet.

>
> The reality is that Chris is failing to convince others of his design
> direction, and is now obviously resorting to manipulation and hominem
> attacks.

Now we can't even talk about technical and  move to personal attacks,
is that all you have left in you?

> During the course of this thread, Chris has asked for "a little faith"
> that his idea will work for all stated requirements, without deeming
> it necessary to explain how.

More FUD please.

> When probed on technical details, he stated that he doesn't like to
> plan that far ahead, and prefers having somebody else iron out the
> implementation details. He also referred to high-level slides from his
> LSFMM '24 session - which was received thusly[1]:
>
>   Matthew Wilcox agreed, warning Li that he was setting himself up for "a world of pain".

Yes, we deal with that pain. Swap table is the outcome so we don't
further impose pain to maintain file cache vs swap cache where a lot
of swap specific optimization will be painful for the file cache side.
As far as I am concerned, the most painful part, swap table as the new
swap cache has already landed. We did not cause Matthew pain in the
process.

>   Jan Kara said that existing filesystem designs are not suited to this task
>
>   Hildenbrand said that this plan was introducing too much complexity
>

More personal attacks please.

> His first response to criticism was to invoke his <4 week status of
> swap maintainer.

I take that back and apologize for what I say and you accept it as "no
hard feelings".
Do you mean you don't mean what you say?

> Meanwhile, the design direction that Chris is construing as a single
> company conspiracy is anything but. The collaborative origins of these
> patches are well documented. Chris was CC'd on those RFCs. He notably

I feel the 48 bytes overhead is a joke, I already provide my feedback
against it in the 2023 LSF swap abstraction. I don't like to keep
beating the dead horse.

> did not engage in them. He is now lying about the narrative and
> choosing to attack these patches in bad faith and out of context.

More FUD and personal attack, is that all you can output now?

>
> This pattern of behavior gives me low confidence that Chris is able to
> collaborate and compromise on a design that works for all users.
>
> And while Chris has been quite vocal and opinionated in mailing list
> discussions, his actual code contributions to the kernel do not
> instill confidence that he can solve this problem by himself, either.
>
> [1] https://lwn.net/Articles/974587/

You obviously haven't graduated from the fact that most of the swap
core is my design now, in the current kernel. There will be more.
More personal attacks please, I am ignoring the attack in the order I
received. It seems that is what is left of you, personal attacks to
dominate a technical discussion when the technical is losing.

Sign, this is an example case study of upstream bullying and that is
why sometimes upstream submission is very unfriendly for the less
established person. I personally know people who were  bullied by you
and give up upstream contributions completely. Go ahead and try to add
me to the list. That will win you more followers. More people will
enjoy working with you.

I agree I am not a native English speaker. I will lose to you in a
bullying shout out flight, you win in.

Let's compete in code and benchmarks and see what happens.

Chris