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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 20393C433F5 for ; Fri, 13 May 2022 13:09:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 634D46B0073; Fri, 13 May 2022 09:09:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BC166B0075; Fri, 13 May 2022 09:09:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 45CD76B0078; Fri, 13 May 2022 09:09:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 33EF86B0073 for ; Fri, 13 May 2022 09:09:53 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EEB5A21435 for ; Fri, 13 May 2022 13:09:52 +0000 (UTC) X-FDA: 79460752224.12.2522F4E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id DF9951C00BC for ; Fri, 13 May 2022 13:09:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Vjkmmhn9V1xJS8Y88P51tDN7F9AxfolLouhb5JjMtWY=; b=vYk77Cm/4AP4+uHJrQ/ed7zFgp BVHbSEi+PeRFDQrix4nlSR5yj97kyHGSyHx+O9iiRBUpfgNJQlqUpNvV7yfYrHxvgVBfS/auhLrea zQLqZM2wnDB1+rJlipLyVQ2ksyaYNaDtRfo/WtHAJJ/pEvCL3KjXHqezrrJtH8YcsUU2ww3+gV8Zf FSjJMvyWDmME58Ai5HlpguPEMAe28CwGOC+bdltsDWYGCZdh7PXIWNm8yDPVHYxaqOCvZH5W/W2pK R+qS8EF0EM+XxXzvb2R8ILtUOcblMHm62+Qas+YHmPlkeHGi8G1gw2H+TwcHNPAxSU3lnaGtnF/Dr kIvfZdbg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1npV2w-007Maw-Sq; Fri, 13 May 2022 13:09:31 +0000 Date: Fri, 13 May 2022 14:09:30 +0100 From: Matthew Wilcox To: Phillip Lougher Cc: Hsin-Yi Wang , Xiongwei Song , Zheng Liang , Zhang Yi , Hou Tao , Miao Xie , Andrew Morton , Linus Torvalds , "Song, Xiongwei" , "linux-mm@kvack.org" , "squashfs-devel@lists.sourceforge.net" Subject: Re: squashfs performance regression and readahea Message-ID: References: <1f8a8009-1c05-d55c-08bd-89c5916e5240@squashfs.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f8a8009-1c05-d55c-08bd-89c5916e5240@squashfs.org.uk> X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: DF9951C00BC X-Stat-Signature: nhk6eomyk18a67tz3yy11a3e1kgs8urn Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="vYk77Cm/"; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-HE-Tag: 1652447381-337072 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: On Fri, May 13, 2022 at 06:33:21AM +0100, Phillip Lougher wrote: > Looking at the new patch, I have a couple of questions which is worth > clarifying to have a fuller understanding of the readahead behaviour. > In otherwords I'm deducing the behaviour of the readahead calls > from context, and I want to make sure they're doing what I think > they're doing. I did write quite a lot of documentation as part of the readahead revision, and filesystem authors are the target audience, so this is somewhat disheartening to read. What could I have done better to make the readahead documentation obvious for you to find? > + nr_pages = min(readahead_count(ractl), max_pages); > > As I understand it, this will always produce nr_pages which will > cover the entirety of the block to be decompressed? That is if > a block is block_size, it will return the number of pages necessary > to decompress the entire block? It will never return less than the > necessary pages, i.e. if the block_size was 128K, it will never > return less than 32 pages? readahead_count() returns the number of pages that the page cache is asking the filesystem for. It may be any number from 1 to whatever the current readahead window is. It's possible to ask the page cache to expand the readahead request to be aligned to a decompression boundary, but that may not be possible. For example, we may be in a situation where we read pages 32-63 from the file previously, then the page cache chose to discard pages 33, 35, 37, .., 63 under memory pressure, and now the file is being re-read. This isn't a likely usage pattern, of course, but it's a situation we have to cope with. > + nr_pages = __readahead_batch(ractl, pages, max_pages) > > My understanding is that this call will fully populate the > pages array with page references without any holes. That > is none of the pages array entries will be NULL, meaning > there isn't a page for that entry. In other words, if the > pages array has 32 pages, each of the 32 entries will > reference a page. That is correct, a readahead request is always for a contiguous range of the file. The pages are allocated before calling ->readahead, so there's no opportunity for failure; they exist and they're already in the page cache, waiting for the FS to tell the pagecache that they're uptodate and unlock them.