From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) (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 4BCF42BE035 for ; Thu, 4 Jun 2026 01:58:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780538317; cv=none; b=QyLJ2L5H7MaIeB1urIXj7Eez8Rpim4GgbbXxb/ifyUceOA6/jEXLPLro2EsEvzCKuF3Pzx5c0LuXx6caNoEmSr/2u/Ycs9qlYKJ8skcs0+o8KuBY7dyePiXFKfUbyCaAX93hdWZYY3eAvJ9QTfriidug3IST6G4w3PVe9FI7tRk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780538317; c=relaxed/simple; bh=wa9XYeHbb9kwdRQLnbUpXOx6qjjsAERqKKJ1t4nbqNo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=S9WjWhtG5S6PuxTG0Ol1MeQ7PUvQXujOe1O6kjsszIqOpvhIXzkSPqxQacoBAL6eH3wQ53/3IhpBSSLQEhd5FEfmN+c8EldcTbiG5Nd/dCr3/S/5G0vfJsDbdb7ktitbo4i6FTE9eaUjxQpRarKENBo5AUiGFJTfpHutxrS8SuM= 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=pCiEp/ih; arc=none smtp.client-ip=209.85.216.44 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="pCiEp/ih" Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-36d5fd50d20so118975a91.1 for ; Wed, 03 Jun 2026 18:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780538315; x=1781143115; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=CnlelyjEPA4eQLtR+vH42NF5EXOCOjHQA+g+i9GlLcA=; b=pCiEp/ihFO9m59VVAbWFw4j47u2kCoav3FV7ntp4XBV+x9Zi8w2L7aDHp926PemqlX BS7bBE4d4Q/9G7SO8nXi/w7SMtgBn5lIDVr3CAA/jk5B9ri4imN5wuIQSBIgueTDns/l 5AhjKLVCFjbOtXQwuqWKWpTQDD7Gv37SuiSiXtmxHMy5aVyXoRcIrBzmOIBudcdcwQOj xmwsi1HWr4KsRhClFsABbRBU2vphLUjCo/3p++AOB7tHTN0jJbbUnb21NWook4xDoVfG Y61CQziUjh0BcqIHqh0ASa+aLy0nCHgVhiwhRcotCiW66NgmtXZkkUgNSj9l7udBwgPj P5zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780538315; x=1781143115; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=CnlelyjEPA4eQLtR+vH42NF5EXOCOjHQA+g+i9GlLcA=; b=g12x9I8YsN1DGBvEaaiT5Z74AvBQjkO3cwWq8hA8lINtDLyV7VODx+2CbDLvTxRAzB PjyPedvArJF53PjLD+wP67nlLDvQZhrjAZUDKRoWyiNQ/FjagJ/08RUHURtuTi/wLzJF Yhm6YHJ+orclarGzaiLq2jZfvCAomMi3qt+4SIhYM7IZ5/SBAU7AtWtpXLYc/kbh959r +UuJcLq/5iXJVqEtCix3bVaOkKEQIJ0eckuN6s/U9UH6nK+CVDbrdrZB3IcMh0E+84uW jld5N/h3ql1aIzhu+kMNsSrmwd7PwqwCQMnv1Zb+gDOG/OoPEISNhPelsCq95ZRQ2G02 vK+g== X-Forwarded-Encrypted: i=1; AFNElJ+p0CXxaqQqrTn69ZkCmuPli57lYa3m56oQBA+8y3Y60F2miYgIpPc42wcmlHn0d6Wzmtz7OWoTafJAWXI=@vger.kernel.org X-Gm-Message-State: AOJu0YxHSi1m1nwF+W/wTfZNpSGuNUoGy5c7MV0qL2cPQJmUmjNn5wa9 Kka4LcObaeYvI14t+2y27aIpM0MHqKnCCCcyM/H62K350N//6v7MZTwX X-Gm-Gg: Acq92OG42N04lKIKNHqUtsLqNMkmEY8NTMy7+B2ZaIn9DBJYP3datKf9wfAgGQxTrId atbsf4Evrv6ywjgc2hQrvC8jGT0/VuL3Dw1OsdjgHUex2YV64ZcYtkXo+IQsaWIkXGuvNQwcYo+ S6qHXdBsPEsDynjh9jl14Qmv+XMo2LyHO5iIC5G61lImQzQ2srUYDHHnIknGvfHmlD1EQOzA91c 5par/SQaeQAVNdxh+Tx1DKeQwIC99FXfsP+tjaJ7KY2/s9UCv7bpKeG3uREHOJxHuuZIMB4tEJN 9UFQFgFT4JV6XfZ3n6zq3ILAOmwdZlQ48ZDiDWC/CnMtiKGaQFzXubkRoFTyFgFPtTByrLLUKN1 ISa8JMURaaBYkIaFUHvVM5c1LWEW/OK4J1tKpfnvwjPTJQkRf0cyw38qLWWwDL2U5C4tZLiahs6 A2ZI3BxZnVV6GMVBjrQO81PBaGx6eIBAtsS2yWvqEgKlXP7JWCnSbaRw== X-Received: by 2002:a17:90b:224e:b0:36d:f28b:72e2 with SMTP id 98e67ed59e1d1-36e32a4281dmr5807810a91.8.1780538315484; Wed, 03 Jun 2026 18:58:35 -0700 (PDT) Received: from [10.125.192.75] ([210.184.73.204]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-36f6dba8064sm1082124a91.12.2026.06.03.18.58.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2026 18:58:35 -0700 (PDT) Message-ID: <9898f83d-fae9-e284-6b85-c7f4089840a0@gmail.com> Date: Thu, 4 Jun 2026 09:58:21 +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 Subject: Re: [PATCH v3 1/4] mm/zswap: Make shrink_worker writeback cursor per-memcg To: Yosry Ahmed Cc: akpm@linux-foundation.org, tj@kernel.org, hannes@cmpxchg.org, shakeel.butt@linux.dev, mhocko@kernel.org, mkoutny@suse.com, nphamcs@gmail.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: <20260526114601.67041-1-jiahao.kernel@gmail.com> <20260526114601.67041-2-jiahao.kernel@gmail.com> <8c0e60e1-5713-69f0-a687-088c87e75764@gmail.com> From: Hao Jia In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026/6/4 01:53, Yosry Ahmed wrote: > On Wed, Jun 03, 2026 at 11:02:54AM +0800, Hao Jia wrote: >> >> >> On 2026/6/3 07:19, Yosry Ahmed wrote: >>>>>>>> Proactive writeback also wants a similar per-memcg cursor that is >>>>>>>> scoped to the specified memcg, so that repeated invocations against >>>>>>>> the same memcg make forward progress across its descendant memcgs >>>>>>>> instead of restarting from the first child memcg each time. >>>>>>> >>>>>>> Is this a problem in practice? >>>>>>> >>>>>>> Is the concern the overhead of scanning memcgs repeatedly, or lack of >>>>>>> fairness? I wonder if we should just do writeback in batches from all >>>>>>> memcgs, similar to how reclaim does it, then evaluate at the end if we >>>>>>> need to start over? >>>>>>> >>>>>> >>>>>> Not using a per-cgroup cursor will cause issues for "repeated small-budget >>>>>> calls" cases. For example, repeatedly triggering a 2MB writeback might >>>>>> result in only writing back pages from the first few child memcgs every >>>>>> time. In the worst-case scenario (where the writeback amount is less than >>>>>> WB_BATCH), it might only ever write back from the first child memcg. >>>>> >>>>> Right, so a fairness concern? >>>>> >>>>> I wonder if we should just reclaim a batch from each memcg, then check >>>>> if we reached the goal, otherwise start over. If the batch size is small >>>>> enough that should work? >>>> >>>> Even with a small batch size, for small writeback requests triggered by >>>> user-space (e.g., 2MB, which is batch size * N), it might still repeatedly >>>> write back from only the first N child memcgs. >>> >>> Yes, I understand, I am asking if this is a problem in practice. For >>> this to be a problem we'd need to trigger small writeback requests and >>> have many memcgs. >>> >>>> This could cause the user-space agent to prematurely give up on zswap >>>> writeback. >>> >>> Why? The kernel should not return before trying to writeback from all >>> memcgs. If we scan the first N child memcgs and did not writeback >>> enough, we should keep going, right? >>> >> >> Yes, this issue is not caused by the kernel, but rather by our user-space >> agent itself. >> >> For instance, suppose a parent memcg has two children, memcg1 and memcg2, >> each with 200MB of zswap (100MB inactive). Triggering proactive writeback on >> the parent memcg will exhaust memcg1's inactive zswap pages. After that, >> even though memcg2 still has plenty of inactive zswap pages, it will >> continue to write back memcg1's active zswap pages. Writing back active >> zswap pages causes the user-space agent to prematurely abort the writeback >> because it detects that certain memcg metrics have exceeded predefined >> thresholds. > > This will only happen if the reclaim size is smaller than the batch > size, right? Otherwise the kernel should reclaim more or less equally > from both memcgs? > I gave it some thought. Not using a cursor could lead to unfairness issues with certain writeback sizes: - If the writeback size is an odd multiple of WB_BATCH (e.g., triggering a writeback of 3 * WB_BATCH), with 2 child cgroups, the writeback ratio might end up being 2:1. - If a memcg has 5 child cgroups and a writeback of 2 * WB_BATCH is triggered, it might repeatedly write back from only the first 2 child cgroups. Although setting a smaller WB_BATCH might mitigate this unfairness, it could hurt writeback efficiency. Let's just use per-memcg cursors to completely fix these corner cases. Thanks, Hao >> Of course, real-world scenarios are much more complex, and this kind of case >> is extremely rare in our environment. >> >> That being said, your suggestion of using the global lock for the per-memcg >> cursors makes the writeback fairer and would resolve these corner cases. > > Right, but I'd rather not do per-memcg cursors at all if we can avoid > it. Will using batches help make reclaim fair over all memcgs without a > cursor? > > We can always add the cursor later if needed.