From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 84221335553 for ; Mon, 1 Dec 2025 16:43:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764607427; cv=none; b=AG0i9y8FDqPP82ikt4H1CrGz2/rkYEK1KPRhbNkoUvwRj89vNfEztx1AOXFOk191r85P5DPGwDIq1Yi9m4BZov+2NxK6QrsLFDx5eHOaiC9MCIfQdwI5DnABQDVczNWALu2z3GnmkaNvxpKjS6nr2bAx+NxTfVQTPjuXwxClcGM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764607427; c=relaxed/simple; bh=0P598M7JbFzPvc1qacqbb/XrsCheq74Cf+DsYQpn6fw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=M22MQmBx3Gf9IOXKpN+rh9rXGVsj15psuXLOtaOEt399WkWnkccuiBFaTbEEbvaQfeRz2UDuB3Ol5+nvJ30Tn4/6pyaqsgdJPm0dwuZImSGPSVnJXLagQB2Yl97BZ+s/J8FRi0yX6HWSgXad+NwW22i0Ot1FVpOmR3H4BLli064= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=RK2cZNDa; arc=none smtp.client-ip=209.85.160.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="RK2cZNDa" Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-4eda26a04bfso48746181cf.2 for ; Mon, 01 Dec 2025 08:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1764607423; x=1765212223; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=W6A3fijvZfqRg56x0MUZazWwowf3lKWT9LWRpRCUaoQ=; b=RK2cZNDaFXqSaxhP+3m7EH+KGSS5aNBkuyEK2z3sZme+Y/JxNoiO8RTb+B9/I/Akhe zBqAqAt+eS/1Ulm5SSboil0nxWNVAfAQP2GJiKtDsAu3Z4nRadeTSfcb6zmpFqNe/7Eo ya7q5jPXh3x28KYvVhcoezygypHhGF/eODj52WQOdIR8i5IZE7YI7LzNkrxqCYOtoFuK 3lWwHe1VIhb7v/AgpNAXC3dsm9ryDcT/NQr1HDc/TLPlRyCbjMAR0O/CjmBi7o6U0uAO JOSQsvkXyiREg0L+fHmlIKzQcfFK5MTD2HXkwqjIwdD1MKVFWAXaqL3ffC8/jVYzY8EL /IbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764607423; x=1765212223; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=W6A3fijvZfqRg56x0MUZazWwowf3lKWT9LWRpRCUaoQ=; b=LtqbcQu+cUK3h7ydH9WsX2PXfsx3OIa6Zcicd90Cbra7vspAPxWdDNQdoTulVU7X9T Al+a9ItTallV/xBIW7XuzVJ7tOoSywg2aIyq9e+732Fa1Z0Hh+4Tz8CQHsXJhRk6P6L8 yJRXJDnHG/Yu8XqBWDflDpvFax1DRLl4mkr6eEoaHLQPqyMWmuZZfhR8e2e/6oJdmQ0l lLE2ZRTxQqec9fLJ4O0y2jgjmRoyfrpYMufO5NYYneeSIZ8BGQgyfkqSKTxoxA4U/SFE t9lmx3atV46sjaOVtu+fcP/MpH6mVSHKEAUulxTCADc8Wm40Wj/sJTVGyDVT4yLRccNY rRSA== X-Forwarded-Encrypted: i=1; AJvYcCUQGAWYRrbW0ZHZUGIvSddka3yem2b5xBhZMjcm5rQi55k9G7Biyj+rYyW/tGnnDLmjNaZMdrPSmVm7+rk=@vger.kernel.org X-Gm-Message-State: AOJu0YzWt/jnqoGSpE89FbOxv8fY6yrU+k70cJOEgaMBv+owW4J1rKcF QmajqJOEYaqBsrIYnSJay/Pe8KpH1Xid7XLMoolVPdcda5n+zRQKzmiukuQkahCF3T8= X-Gm-Gg: ASbGncvm7u7kX0wusZ27u48B6TsJI2WICJ8NYwgM0Ta3DM1gnNP1Le05c9NZWk9WS0k W3Adf89G8f8ZwIJc+Hsq+SgDnlqzdiIQ8YoCzq2syYfwablaoZ2f0ZSp8JLszhSbA9+eH4uOLPz 7E4gLm9Fqla7r4TuQQZ1ah7Du4O0ITXcljJhWII7I2ZFHE97U5suE6ENA59gdfsiybxbaH2Ry4Y iOWAM/3xO+PQR2B+Gmnn85agSVSvGv/cm0uZBqar9Kws0zj8sDuiMq9ieggjCGvUJnEXSYTPLU5 8tzp6JrSC+3U3iy6ErleNuWpcJu6FhhMg6L/AABZUuEDGSIpdQTOALENaVakqrWKSNnGDab84fP 63YCOwh4yfIsGdq9zTYkHrhR+NVusW3XPBc5XKn8Gp92wTfN/tjDX9vnimFGlaclf4+GfeKQ3iW uf120KCDrLzw== X-Google-Smtp-Source: AGHT+IFL5Gt3eXeZB/NaqJ6KrE/7BeAcxNBW82wvFuHKT1wVq74KiJ5+vkjNBzMAeSnRSDqxnyXvvw== X-Received: by 2002:a05:622a:44a:b0:4ed:b94c:774a with SMTP id d75a77b69052e-4ee58841e9bmr606786671cf.5.1764607422936; Mon, 01 Dec 2025 08:43:42 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:929a:4aff:fe16:c778]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4efd2f9a3b5sm77523881cf.1.2025.12.01.08.43.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Dec 2025 08:43:42 -0800 (PST) Date: Mon, 1 Dec 2025 11:43:38 -0500 From: Johannes Weiner To: Chris Li Cc: Nhat Pham , Rik van Riel , Andrew Morton , Kairui Song , Kemeng Shi , Baoquan He , Barry Song , Yosry Ahmed , Chengming Zhou , linux-mm@kvack.org, linux-kernel@vger.kernel.org, pratmal@google.com, sweettea@google.com, gthelen@google.com, weixugc@google.com Subject: Re: [PATCH RFC] mm: ghost swapfile support for zswap Message-ID: <20251201164338.GA430226@cmpxchg.org> References: <20251124193258.GB476776@cmpxchg.org> <20251125213126.GB135004@cmpxchg.org> <7665130c511e3cd00f83e8b14de2b78e08830887.camel@surriel.com> <7e44e8654eb0ed5e0f590b3d705b258772dadb57.camel@surriel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Sun, Nov 30, 2025 at 12:38:38AM +0400, Chris Li wrote: > On Sat, Nov 29, 2025 at 12:46 AM Nhat Pham wrote: > > > > On Thu, Nov 27, 2025 at 11:10 AM Chris Li wrote: > > > > > > On Thu, Nov 27, 2025 at 6:28 AM Rik van Riel wrote: > > > > > > > > Sorry, I am talking about upstream. > > > > > > So far I have not had a pleasant upstream experience when submitting > > > this particular patch to upstream. > > > > > > > I really appreciate anybody participating in Linux > > > > kernel development. Linux is good because different > > > > people bring different perspectives to the table. > > > > > > Of course everybody is welcome. However, NACK without technical > > > justification is very bad for upstream development. I can't imagine > > > what a new hacker would think after going through what I have gone > > > through for this patch. He/she will likely quit contributing upstream. > > > This is not the kind of welcome we want. > > > > > > Nhat needs to be able to technically justify his NACK as a maintainer. > > > Sorry there is no other way to sugar coat it. > > > > I am NOT the only zswap maintainer who expresses concerns. Other > > people also have their misgivings, so I have let them speak and not > > put words in their mouths. > > You did not mention the fact that both two NACK from zswap maintainers > are from the same company. I assume you have some kind of team sync. > There is a term for that, called "person acting in concert". 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. The reality is that Chris is failing to convince others of his design direction, and is now obviously resorting to manipulation and hominem attacks. 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. 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". Jan Kara said that existing filesystem designs are not suited to this task Hildenbrand said that this plan was introducing too much complexity His first response to criticism was to invoke his <4 week status of swap maintainer. 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 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. 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/