From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BBB47C433F5 for ; Tue, 19 Oct 2021 17:54:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7177C61360 for ; Tue, 19 Oct 2021 17:54:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7177C61360 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 0F902900004; Tue, 19 Oct 2021 13:54:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A947900002; Tue, 19 Oct 2021 13:54:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F024F900004; Tue, 19 Oct 2021 13:54:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0057.hostedemail.com [216.40.44.57]) by kanga.kvack.org (Postfix) with ESMTP id E1C58900002 for ; Tue, 19 Oct 2021 13:54:34 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 9C1643E565 for ; Tue, 19 Oct 2021 17:54:34 +0000 (UTC) X-FDA: 78713936868.10.38E811A Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf08.hostedemail.com (Postfix) with ESMTP id C022830000AC for ; Tue, 19 Oct 2021 17:54:30 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 5328860F57; Tue, 19 Oct 2021 17:54:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1634666073; bh=0lmHBiMAYwQI6ZLGGLhhIuhQ0S+abmoZURDHJhYO9DE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YxBiacY1zC4MphhR5iKglY+9y5xo38OaiVqWRhG40SjtxcNvYiFUV52YxQ20WiKeU wjhebfLkt4veySjZg7gP3hEJsJtsCymcp1asP5F8l2sHwCHMOoS0pHok8lD51j5pYE U1aB58E8NZtIwCOPQWtnGKgLBb9+ajDlzgucylgz0BkBgn/K/+L/5GSe+Oi/ITmkNf FLrQ7hD62IYXvvi++fBwsTfoKBoJNQW6Yy8JXg9M9LSRRdTS5tUPC20hx8250NeTNV 4MNuv/iD4bq4vSZ3ZD2op3k61ZVbgWIdaq4ip/tI0orZDJZ9GgfdVWWTVT3fDhL9UI 20j8dCjUWZmTA== Date: Wed, 20 Oct 2021 01:54:20 +0800 From: Gao Xiang To: Matthew Wilcox Cc: Kent Overstreet , Johannes Weiner , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , "Darrick J. Wong" , Christoph Hellwig , David Howells Subject: Re: Splitting struct page into multiple types - Was: re: Folio discussion recap - Message-ID: <20211019175419.GA22532@hsiangkao-HP-ZHAN-66-Pro-G1> Mail-Followup-To: Matthew Wilcox , Kent Overstreet , Johannes Weiner , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , "Darrick J. Wong" , Christoph Hellwig , David Howells References: <20211019170603.GA15424@hsiangkao-HP-ZHAN-66-Pro-G1> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C022830000AC X-Stat-Signature: hyk56si7w86uj7iyypcm9eianccw14gw Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YxBiacY1; spf=pass (imf08.hostedemail.com: domain of xiang@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=xiang@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1634666070-604640 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Matthew, On Tue, Oct 19, 2021 at 06:34:19PM +0100, Matthew Wilcox wrote: > On Wed, Oct 20, 2021 at 01:06:04AM +0800, Gao Xiang wrote: > > On Tue, Oct 19, 2021 at 12:11:35PM -0400, Kent Overstreet wrote: > > > Other things that need to be fixed: > > > > > > - page->lru is used by the old .readpages interface for the list of pages we're > > > doing reads to; Matthew converted most filesystems to his new and improved > > > .readahead which thankfully no longer uses page->lru, but there's still a few > > > filesystems that need to be converted - it looks like cifs and erofs, not > > > sure what's going on with fs/cachefiles/. We need help from the maintainers > > > of those filesystems to get that conversion done, this is holding up future > > > cleanups. > > > > The reason why using page->lru for non-LRU pages was just because the > > page struct is already there and it's an effective way to organize > > variable temporary pages without any extra memory overhead other than > > page structure itself. Another benefits is that such non-LRU pages can > > be immediately picked from the list and added into page cache without > > any pain (thus ->lru can be reused for real lru usage). > > > > In order to maximize the performance (so that pages can be shared in > > the same read request flexibly without extra overhead rather than > > memory allocation/free from/to the buddy allocator) and minimise extra > > footprint, this way was used. I'm pretty fine to transfer into some > > other way instead if some similar field can be used in this way. > > > > Yet if no such field anymore, I'm also very glad to write a patch to > > get rid of such usage, but I wish it could be merged _only_ with the > > real final transformation together otherwise it still takes the extra > > memory of the old page structure and sacrifices the overall performance > > to end users (..thus has no benefits at all.) > > I haven't dived in to clean up erofs because I don't have a way to test > it, and I haven't taken the time to understand exactly what it's doing. Actually I don't think it's an actual clean up due to the current page structure design. > > The old ->readpages interface gave you pages linked together on ->lru > and this code seems to have been written in that era, when you would > add pages to the page cache yourself. > > In the new scheme, the pages get added to the page cache for you, and > then you take care of filling them (and marking them uptodate if the > read succeeds). There's now readahead_expand() which you can call to add > extra pages to the cache if the readahead request isn't compressed-block > aligned. Of course, it may not succeed if we're out of memory or there > were already pages in the cache. Hmmm, these temporary pages in the list may be (re)used later for page cache, or just used for temporary compressed pages for some I/O or lz4 decompression buffer (technically called lz77 sliding window) to temporarily contain some decompressed data in the same read request (due to some pages are already mapped and we cannot expose the decompression process to userspace or some other reasons). All are in the recycle way. These temporary pages may finally go into some file page cache or recycle for several temporary uses for many time and finally free to the buddy allocator. > > It looks like this will be quite a large change to how erofs handles > compressed blocks, but if you're open to taking this on, I'd be very happy. For ->lru, it's quite small, but it sacrifices the performance. Yet I'm very glad to do if some decision of this ->lru field is determined. Thanks, Gao Xiang