From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) (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 5894A3ED3BA for ; Mon, 24 Aug 2026 10:08:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787566085; cv=none; b=D5g7oiWWg+A62kuztRVE5W8kWf8fcqOhtCN185mU7hUStn3PucYwlXTMwQNmYAYOgim4Fe8bRKdfjDw4vViUOjADgVu0nKaTRKlj6MVjjFqQqR61siYpJ7CB0XlLtVYMf/K0ctLv8YPpesdmGqKwrWU8JQ5+sf6h81z17ELuAIQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787566085; c=relaxed/simple; bh=JchDbe3/4eWPjLGW3PyI3BZpqUZt4tEbDz7LesTJELY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mk1ssZDZOyyRjqm/ojtp3z0vAH1Mudofm18MxjR42q8alaMcmfd2/iV0fiw/VFyAdNI/bNCs5Dyy+n3gtVAxSTqaSwBvYCnyIM/aYmk4Vnpa1um3ZvPHwJRqhZaTw8KPe+KtT2FHHYC0lHStb7rmeIPZ5+zWx8QwtA77xbZBty0= 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=gQeKkEST; arc=none smtp.client-ip=209.85.215.178 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="gQeKkEST" Received: by mail-pg1-f178.google.com with SMTP id 41be03b00d2f7-cbedf433a99so3208287a12.2 for ; Mon, 24 Aug 2026 03:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787566084; x=1788170884; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=cQht530mieFUeugmQqlDH51hivGpkoJbD3uSg8tM2y8=; b=gQeKkESTv+GC7Uu8uOAc2aoxFbGO0k3joCviVjW9bUtJ4Y9a0Rqs9NvGThtSFE1Jsg yYgABTn9yopbSMIMQyON7FVc6RSxNuua4ROVEi8SnIUBrfimUlCRgCslJ3K+QxBky9Og 4erGDPqgsFZtqpRdCQYw14WTDVqDgPaL7lteZc6p8yK6bZbQYLlhBwPvUqQlpnlF29mF fhIHf/PHgW5ENIB/jcB90+WrRBlhmiJs7SNeIwL22zVWbWhyLBbHn2MMVOG0pyRNJ4Po T8CZI19C0y6l4kxxhbfwoWlmrRZOm2aZjDxGAdkPqp+R5e/TI5wd61BeI9fLfuMyuFhU 7kkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787566084; x=1788170884; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=cQht530mieFUeugmQqlDH51hivGpkoJbD3uSg8tM2y8=; b=rlkQBw8u9SfW1EsqBlw5Wr8g0jK9vP2ITllgDw4ARfJu4yLGFNtuMWRJYsni8VyXna YSeljsa0X3FrZ4didP1/yWVvpC0EnvDoNlhSDQt/Fo3hv/nXBJi6f6pVVvgOiLEVkiYI xLkJWkHkrq4Z8tz1HIArgHudDODehiWg45tVV09ds110R96aJ1QNp0iHFCZQjVGzF1EX dcB/Ek5DGHfkM7+bUeHId05drhg+1/5tZi2JEpKpf2PekkCvmx8GZBTpR72JrdIMqTa1 GknAIVnKf8LtKUP3ghtnyDzBWlbCqI//MoLM1p98ZM2q+G/TY8HW3DrX8SgPwGt4r/uR 94wA== X-Forwarded-Encrypted: i=1; AHgh+RoneU9hXNl8LWUeRXkPYi0mt2ZUTQVSWEhxyW8sIxC638f52nvkzQ6DpMmvI1XKOhVTKhw8kYmixidYZ0s=@vger.kernel.org X-Gm-Message-State: AFuF++ldMJXQ/JDYyw8DmavbHe6Wv9MG+dn1LLfA+7NwjusNCxaiJ7Sr TMcGkG8UIX+vkS53lUtmM2jfnPDC4l93O1E7gKzegOvF7S+rWIDkPoT+8HHXcElg X-Gm-Gg: AR+sD10q4aP5Kto+iYovqvGapxj6WX0PBFU2iegrRQiEGWWXrgCGInMDYDJJGXNwu9W UqOAm3MyuqEr+kCSPnZkC+pnTczsznWJK/p/tdJXZLroXuwNFnBqfhlmKjJ5f8EtZcfs2OWP+zB t5faUDz2y1oqzCARNBhfVsAgIme2IL+5jNB6zyS5FIM+VPyajtrAtrSJf0+Fs3JmpmbFM5//UFV lq7+W/NLUC0PPaoNQQ7y9FZUhIi/UnE826cVgXdzGez/oEn2NuM6961o+RivI4KDxWs2VKLMj2E GqPlVYQMeKJb4Mc8gdvA/d1q14mONiM6uXjumyGI3WEkzxVZRbOgx7x2Galva92Rwbpofti9gO/ 69hXpiDtB2L6BX7D0MjGAaRWfAvzYPehUwl+ODUhXWQx0FrIXQ6UTtX4NuLxn0nHwyuWngnLWYZ UoiNDlynK2MP3VNUzJFhTKYC9VeFvrmvSnK3CdYM7KcEloB3X+Er4Fu5VfzP3ojZim3ZzibfUUd +KLBJD9bDvByZl+bHOBOQ== X-Received: by 2002:a17:90b:2712:b0:395:543a:cf3b with SMTP id 98e67ed59e1d1-395c3518185mr49198167a91.2.1787566083683; Mon, 24 Aug 2026 03:08:03 -0700 (PDT) Received: from qiwenjie-ThinkCentre-M760t.mioffice.cn ([43.224.245.241]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-395e4999471sm9433393a91.8.2026.08.24.03.08.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Aug 2026 03:08:03 -0700 (PDT) From: Wenjie Qi To: Chao Yu Cc: Wenjie Qi , Jaegeuk Kim , qiwenjie@xiaomi.com, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [PATCH v1 00/12] f2fs: introduce metadata cache Date: Mon, 24 Aug 2026 18:07:52 +0800 Message-ID: <20260824100752.3890850-1-qwjhust@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260820031721.12218-1-chao@kernel.org> References: <20260820031721.12218-1-chao@kernel.org> 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-Transfer-Encoding: 8bit Hi Chao, At Xiaomi, we have an out-of-tree F2FS node-cache prototype for mobile workloads that retains clean node contents in compressed memory after page-cache reclaim. This is different from this series: F2FS_NODE_CACHE is the primary cache and can hold dirty authoritative data, while our compressed contents are clean and disposable. In our mobile workloads, clean F2FS node pages can represent roughly 100 MB of uncompressed working-set memory. We have observed an LZ4 payload-to-original ratio of about 0.1 for these pages, excluding zsmalloc fragmentation, entry metadata, and workspaces. Node reads are also on latency-sensitive paths, while memory pressure can repeatedly reclaim and later reread the same node pages from storage. These are observations from our out-of-tree mobile workloads, not benchmark results from this series or current upstream Linux. If the primary metadata-cache model moves forward, the direction we would like to explore is one F2FS_NODE_CACHE slot per NID with mutually exclusive clean representations: UNCOMPRESSED_CLEAN <-> COMPRESSED_CLEAN Active, dirty, and writeback entries would stay uncompressed, and a slot would not retain stable copies in both forms. Compression would be prepared outside the shrinker and direct-reclaim paths. Shrinker reclaim would continue to discard clean entries without compression, allocation, or I/O. If an optional compressed representation for clean, idle F2FS_NODE_CACHE entries fits your intended metadata-cache roadmap, would it make sense to discuss the clean-entry state and lifetime contract first, and prototype it on top of v2 once the base cache is ready?