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 35B30C433F5 for ; Mon, 16 May 2022 12:48:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3979A6B0071; Mon, 16 May 2022 08:48:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3487D6B0072; Mon, 16 May 2022 08:48:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20F636B0073; Mon, 16 May 2022 08:48:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 12E516B0071 for ; Mon, 16 May 2022 08:48:20 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E08CD61B9C for ; Mon, 16 May 2022 12:48:19 +0000 (UTC) X-FDA: 79471584318.05.EBC3CA2 Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) by imf08.hostedemail.com (Postfix) with ESMTP id A8C6F1600C8 for ; Mon, 16 May 2022 12:48:02 +0000 (UTC) Received: by mail-vs1-f44.google.com with SMTP id v139so15419558vsv.0 for ; Mon, 16 May 2022 05:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tPZL+h8jcnBW8PHWzi1Lq2sdX5BxnED0XWH1cfUGZUM=; b=DEZpbOgEvpT0/mw7g8WxEqnXML+QP8L1f8t8EVAx5s6EJcEal8pQJc72+LahAsseMq jxB1+F3/ufWv217kKKmVIIay1JoTF+vO0ReKEN4pFmokQ6DwS263F0437nEDO79rvDTg lLyLQLHmMI0I70TkS9sgr7H2lgaMMthSrfP3k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tPZL+h8jcnBW8PHWzi1Lq2sdX5BxnED0XWH1cfUGZUM=; b=RSzDzLOxsiXF+85fTJfnPn1o0Zk1wcp3nMzd+RCmY6tc7bXNewGkLh4lKiy/n5pbsn vzXSezz4nyZclTZQu5aTCEZZdDdaMFuzcZDQCHTaBHaLdNyLTuu9OptOFPH2RTUghd4T rKz+dIUXsln3YFIdQqkc7cN4vOty8HS9Y3DxQy6YVa7n6N08vI+B3wmToRSZ1j6hfgGq cAy3wSjBG9XpddcUmQpijW7+mDFYfM307m00jr3prCWRG4sRM4iJQJSPf+HGBC7G+d2W AVeil7g/fLoBk3E0DZBqCKmFlOh16C6x5leVqQZx5a1QGAuIFNUyl9X8K/5cy9BxaqKZ mYpQ== X-Gm-Message-State: AOAM532NymK4ujkrBEzR4FybTF4AJT+QKxBEaEGuhU6AJxe5JuEha/+f qLKCDIUKMHVoPmsCFWnfHU/0eJLthp9cfwGRbQhI9w== X-Google-Smtp-Source: ABdhPJyFGR82c/fth2bgKdRpk7amgaoBeyp1CambTvVyEA4sPHZFBf0Us5CA+S0ti98tO7thswX8hquoKaAZAoNpccU= X-Received: by 2002:a67:d999:0:b0:335:7e5c:63d5 with SMTP id u25-20020a67d999000000b003357e5c63d5mr4976709vsj.69.1652705298452; Mon, 16 May 2022 05:48:18 -0700 (PDT) MIME-Version: 1.0 References: <20220516105100.1412740-1-hsinyi@chromium.org> <20220516105100.1412740-3-hsinyi@chromium.org> In-Reply-To: From: Hsin-Yi Wang Date: Mon, 16 May 2022 20:47:52 +0800 Message-ID: Subject: Re: [PATCH 2/2] squashfs: implement readahead To: Matthew Wilcox Cc: Phillip Lougher , Xiongwei Song , Zheng Liang , Zhang Yi , Hou Tao , Miao Xie , Andrew Morton , "linux-mm @ kvack . org" , "squashfs-devel @ lists . sourceforge . net" , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 6r9mo9g15wepop8bs5tpzsg11wopf3x9 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A8C6F1600C8 X-Rspam-User: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=DEZpbOgE; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf08.hostedemail.com: domain of hsinyi@chromium.org designates 209.85.217.44 as permitted sender) smtp.mailfrom=hsinyi@chromium.org X-HE-Tag: 1652705282-150411 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 Mon, May 16, 2022 at 8:36 PM Matthew Wilcox wrote: > > On Mon, May 16, 2022 at 07:04:08PM +0800, Hsin-Yi Wang wrote: > > > + loff_t req_end = readahead_pos(ractl) + readahead_length(ractl); > > > + loff_t start = readahead_pos(ractl) &~ mask; > > > + size_t len = readahead_length(ractl) + readahead_pos(ractl) - start; > > > + struct squashfs_page_actor *actor; > > > + unsigned int nr_pages = 0; > > > + struct page **pages; > > > + u64 block = 0; > > > + int bsize, res, i, index; > > > + int file_end = i_size_read(inode) >> msblk->block_log; > > > + unsigned int max_pages = 1UL << shift; > > > + > > > + readahead_expand(ractl, start, (len | mask) + 1); > > > + > > > + if (readahead_pos(ractl) + readahead_length(ractl) < req_end || > > > + file_end == 0) > > > + return; > > What's the first half of this condition supposed to be checking for? > It seems to be checking whether readahead_expand() shrunk the range > covered by the ractl, but readahead_expand() never does that, so I'm > confused why you're checking for it. hi Matthew, This is to check if readahead_expand() expands as much as it's requested. I didn't encounter the mismatch so far in my testing. If this check is not necessary, it can be removed.