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 4C6A8C433FE for ; Mon, 16 May 2022 12:57:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D522E6B0071; Mon, 16 May 2022 08:57:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D01756B0072; Mon, 16 May 2022 08:57:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA2A46B0073; Mon, 16 May 2022 08:57: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 A7F3C6B0071 for ; Mon, 16 May 2022 08:57:53 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 85EB733C97 for ; Mon, 16 May 2022 12:57:53 +0000 (UTC) X-FDA: 79471608426.08.798ECCA Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) by imf26.hostedemail.com (Postfix) with ESMTP id E6B631400C1 for ; Mon, 16 May 2022 12:57:49 +0000 (UTC) Received: by mail-vk1-f175.google.com with SMTP id h144so7460377vkh.3 for ; Mon, 16 May 2022 05:57:52 -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=o8xDKjeA5vjhnmsZaoY94PaYuZJ/k/2yUmf/Dmij7ao=; b=IIAZ2Vr+cKp9N/hE450cPXfGMc4W6fTjUA8NYQM8OGAxXmIn1uHumxtB8a/sB6412j 7sdniG4owzBih4e4mPYRlB3BXJ01DS3cwu+86vHTAJNTxcICEueQB4LSBWAXb4H9CYav /1AyHO5SDWCl65RbUtarwktsst7MJJfImV4wA= 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=o8xDKjeA5vjhnmsZaoY94PaYuZJ/k/2yUmf/Dmij7ao=; b=ewNeCTmU/BjgIjliHl5i8DpA78GACAUMw8NR7wqMI0b8uiut7807GvV5Ki2zliFmyG aJgDSRBNTYlvo1lqBhHmFvh/IGRYaEf8fMxYiS7NORL6kH68XJ4k/lclOyurGNDk3iVa 2Y7cpocddHuQRRHuBcJTum16OaPusI66K7ZyJJf3PoFUBzS/9RUZfGRs3xlEhGxJ2CL1 7PnPPWU8rYJu4vA0dufnAMbIOsBFCe6VISUk755pf6GCMB5oOkMZnhzsYSzkZDNpMHzs twXwr3n8vpE66PRGJ9jWjrx3myJKzPnsVUXuNLz2dyUMCS6zSODtDMFjMwr0K6SsTOwG GEjA== X-Gm-Message-State: AOAM532Il8Ft1XQZjb/aB98m0KkH7bYuQ9jXMZJT62lZ5PIQIET0+s1j mtjdJfMFkYoDDvqAxVr968s9LvR0phyVXXRA7q/Uug== X-Google-Smtp-Source: ABdhPJzbR154HdykUqMlOSgdS61sMbReXdsrDnc05byBsyuvClGk3qSBPM5na8t5c/P9iHuHZlbfFJyxBc7kjWU87L4= X-Received: by 2002:a05:6122:da8:b0:331:3b30:8b40 with SMTP id bc40-20020a0561220da800b003313b308b40mr5898585vkb.30.1652705872210; Mon, 16 May 2022 05:57:52 -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:57:26 +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: wpuemxbez8apspxqwu7o18he6nt3115t X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E6B631400C1 X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=IIAZ2Vr+; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf26.hostedemail.com: domain of hsinyi@chromium.org designates 209.85.221.175 as permitted sender) smtp.mailfrom=hsinyi@chromium.org X-HE-Tag: 1652705869-974124 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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:55 PM Matthew Wilcox wrote: > > On Mon, May 16, 2022 at 08:47:52PM +0800, Hsin-Yi Wang wrote: > > 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. > > Then I think req_end is miscalculated? It should surely be: > > req_end = start + (len | mask) + 1; > > But I'm not sure that we should be failing under such circumstances. > For example, we may have been asked to read 1.5MB, attempt to round up > to 2MB, and fail. But we can still submit a readahead for the first 1MB, > before leaving the second 512kB for readpage to handle. > > So maybe we should just remove this check entirely. I'll remove this in the next version.