From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) (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 7193B146D53 for ; Mon, 15 Jun 2026 02:45:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781491560; cv=none; b=H8WUs9LQcXKW8Jj8P0wIPSCIw16+zkk89C7ZKaB7HsVBjrZN6nainGhs9lzEMgbKbO6fPAdK9rMfTJDiKaQyGOUEDtQSDfnoo7JjJPhF+GIb+HJni9oLbCSWIO6OtQL3a6qTX/T+Lp/FBHzGcJH66oixJQDCljs4oUr6bkmbL2k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781491560; c=relaxed/simple; bh=aR4W3BEIH8IzDqlwprPAbjrY4D4yzLAM0ofXLYgoDYs=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=gw0BnZ3uc1e0IwfVYIg3mzttIEP8SinWu17Ll+XXilJw+oHQ2AtJY7of5Cviomro9fWcVQLV+yxYoC2I5w0oI44P6SaPfIfszBBp1S25iTyxHhPd99wzBEnlRb/I6gTvkzx4Z63cXemUGPbARbcFYv4m5Zhub2X6BWRj0jsoAeU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Jag6rI1F; arc=none smtp.client-ip=209.85.210.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Jag6rI1F" Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-842338c18e0so2025412b3a.1 for ; Sun, 14 Jun 2026 19:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781491559; x=1782096359; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:references:cc:to:subject:from :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=e8NLHGVjFApYnrN7TuvQPcE5946BfMaA9XvCk6482m8=; b=Jag6rI1FMUqPi5tSLDwGSR6NxRdjU+vayODZsRp0rQ3m1EApo+64kJLcIGGhO8XDpy FtPdzyOsJTJHkguVvLw5D+DKeuuRInNpzO6Ypj/a6wGADl6kIJy08JE9/Dof+KOwDlAf nc8hdtZGmzlZ1VJf/0d7sLDvhONy09yOa9TgWpm6QJa+S4W5dTYVYvi1zVPw0fjZFYoL 6m0b2KReYsgGxpjNzz1VcDS6S+RVeFciMph+ISAgmQmcaVYOyht/qjM2a52BqoPNvoiJ tTsn4lgdsljYSTAMk/iZZJ6buuDFA0hh7gvEQdAm9vVld9lMKMIwJ2QBqyqEiOz7yHcg ZEcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781491559; x=1782096359; h=content-transfer-encoding:in-reply-to:references:cc:to:subject:from :user-agent:mime-version:date:message-id:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=e8NLHGVjFApYnrN7TuvQPcE5946BfMaA9XvCk6482m8=; b=UseeaxoXVOAh2Rhf5YEylIhMxE2hUOs8cs+M/xQQk9PsfIm+hN9Rf+K9OGGOucywr0 GNRho4kyKRFHG5MoGXdCeNZcSsGxSkvwhK30/wJEnM2/07I2IBXyodCKkmChkz0PeCv2 QkQ+rwkdVrsUi+iRXxPiZgQyoqx0P4Q+xkjR4wPFLc9yfQxXk8/nkWG/tIq4+SL6O3cX KDwh6K2FcVQ769ocZ6NObwpTnRsIDyXxLq41NTFV0A5isgWbY3VB77xWhHA3FFvunrC+ Hc+Ns8/424mbT34zUkxB89XLSanINKP40abiSyP/kguviV4ePiv9IPQlGzxCZB5w+6c1 6SvA== X-Forwarded-Encrypted: i=1; AFNElJ8ctXCAzynW6j6a8Jm96w0VDOhkJ5Blp++v3rjIMNaL67KXp8z5OrtBsxFDMNt0QG56RFpQQKu0arvWLBY=@vger.kernel.org X-Gm-Message-State: AOJu0YykCvFcMclyzaniAWHfWjxtgTaYTFoncWKk55md0JSYito4JEwA iwz7qkbxfZ1JfUtU0ur4+qO3yN30BmRc94JlVkhqYqk5zPlkyehQHYtx X-Gm-Gg: Acq92OG2sd+de914xUcYhPX/SX2XvkMPw6m89QkPzEkvjjXPlewFBJ0BeyyW9QO79es n2onLFsxYgEOjCmn4NCbumqczgYt3/jI6Sv5tt0e29qE1rkuS//R5deRTc6Bc4Kyzpv4hx8N3FW +NJm86GjivocXfSZu5EkdOvKVdtA45VpYYo3o1XNgUdqNq3MY0/GAOZDQSutb9xqidhKxLLtm+h HCkH7wCUzsjadlrNDF1q4ndbLGK2KlEo3h9Ik19ZqaQlYD40zIApHNMZc8iJjAcQn2YwMeN/Ul3 ZKPpu4HSCwmIGw9eNTDUqz30WBoGff9oRtHbrs6QzeBE5l5yXuXY/c8rJjLX9Cn2HEYit0E620w 3RymbZulSFkZN67B+nNaeauu9uP5xABo53rNbbVV1Yo8fO4wVDNnK9OBTa4U0FH0Ad8eONeZgXB IR1Kxv5uCHSaMi3Wgc+mWy+IvjcmExaF2QfaYMMmmA4wLz+vuZFA== X-Received: by 2002:a05:6a00:400b:b0:83a:3135:edbd with SMTP id d2e1a72fcca58-844e1931335mr9663347b3a.7.1781491558659; Sun, 14 Jun 2026 19:45:58 -0700 (PDT) Received: from [10.125.192.102] ([210.184.73.204]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8434b05921bsm8343847b3a.59.2026.06.14.19.45.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Jun 2026 19:45:58 -0700 (PDT) Message-ID: <128c28a1-71b5-d435-fb1a-9882c23727ca@gmail.com> Date: Mon, 15 Jun 2026 10:45:20 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 From: Hao Jia Subject: Re: [PATCH v3 1/4] mm/zswap: Make shrink_worker writeback cursor per-memcg To: Yosry Ahmed , Shakeel Butt Cc: Nhat Pham , akpm@linux-foundation.org, tj@kernel.org, hannes@cmpxchg.org, mhocko@kernel.org, mkoutny@suse.com, chengming.zhou@linux.dev, muchun.song@linux.dev, roman.gushchin@linux.dev, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Hao Jia References: <9898f83d-fae9-e284-6b85-c7f4089840a0@gmail.com> <90730fa7-62e7-d5f4-b638-23b22a8509f2@gmail.com> <1c25650e-bf98-2863-d505-9b94c385668b@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2026/6/13 02:15, Yosry Ahmed wrote: > On Fri, Jun 12, 2026 at 9:40 AM Shakeel Butt wrote: >> >> On Thu, Jun 11, 2026 at 05:39:16PM +0000, Yosry Ahmed wrote: >>> On Tue, Jun 09, 2026 at 11:18:26AM +0800, Hao Jia wrote: >>>> >>>> >>>> On 2026/6/9 02:01, Nhat Pham wrote: >>>>> On Mon, Jun 8, 2026 at 9:48 AM Yosry Ahmed wrote: >>>>>> >>>>>>> But OTOH, this does seem like a recipe for inefficient reclaim. We >>>>>>> might exhaust hotter memory of a cgroup while sparing colder memory of >>>>>>> another cgroup... But maybe if they're all cold anyway, then who >>>>>>> cares, and eventually you'll get to the cold stuff of other child? >>>>>> >>>>>> Forgot to respond to this part, the unfairness is limited to the batch >>>>>> size per-invocation, so it should be fine as long as you don't divide >>>>>> the amount over 100 iterations for some reason. Also yes, all memory >>>>>> in zswap is cold, the relative coldness is not that important (e.g. >>>>>> compared to relative coldness during reclaim). >>>>> >>>>> Ok then yeah, I think we should shelve per-memcg cursor for the next >>>>> version. Down the line, if we have more data that unfairness is an >>>>> issue, we can always fix it. One step at a time :) >>>> >>>> Thanks a lot to Yosry, Nhat, and Shakeel for the great suggestions! >>>> >>>> Let me summarize what I plan to do in the next version to make sure we are >>>> on the same page: >>>> >>>> - Drop the per-memcg cursor and keep the root cgroup cursor >>>> (zswap_next_shrink) logic intact. >>>> - Stick to using the zswap_writeback_only key, and change the proactive >>>> writeback size to use the compressed size. >>>> - Consolidate and reuse the logic between shrink_worker() and >>>> shrink_memcg(). Enable batch writeback in the shrink_worker() path, while >>>> keeping the writeback behavior in the zswap_store() path unchanged. >>>> >>>> Please let me know if I missed or misunderstood anything. Thanks again for >>>> clearing things up! >>> >>> Sorry for the late response, yes I think this makes sense. However, I >>> have some comment about how this interacts with swap tiering, let me >>> reply to the other thread. >>> >> >> I think the swap tiers interaction will be figured out over next cycle. However >> Hao can/should continue to push and we may decide to let it in orthogonal to >> swap tiers. > > Yeah I think there are a lot of changes we discussed outside of the > memcg interface, so maybe keep the interface as-is for now, work on a > new version with the other changes, and we can finalize the interface > at the end? Okay, I will split the non-memcg interface parts into a few separate patches. These will serve as the preparation work for proactive writeback and enable batch writeback in the shrink_worker() path. However, I will still send the complete patchset using the zswap_writeback_only key approach in the next version. This should make it easier to review whether the preparation logic is reasonable, and to decide whether it should eventually be merged independently of the swap tiers. Thanks, Hao