Received: by 2002:ac2:464d:0:0:0:0:0 with SMTP id s13csp3283492lfo; Mon, 23 May 2022 00:39:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyRSQMBa+zehAVY2dzFx+SCnf0PCHwNpP2Q6asxrq94kvwNuT7a/+dK4wTWZVgmBN1zhf2F X-Received: by 2002:a05:6a02:117:b0:3fa:de2:357a with SMTP id bg23-20020a056a02011700b003fa0de2357amr7320350pgb.169.1653291589847; Mon, 23 May 2022 00:39:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653291589; cv=none; d=google.com; s=arc-20160816; b=Wu2+ltrurSNULuk1rcKJrNfd/MtrI/wyuZIb0sCGxySG+oE1HBlxA/XoVaVqYsXd2i OUYZ0wyUv5d2xmthrZXKSIjbHL/8IQJylaW1t+VBT0ezwV3CQWmOzSyhjiFiX2o8F8HT UaqmKPY7kVjydl000j/4EWaznZDWMgfzNt8kZT6wzNfbbkC0TqMAusUx1zbOlooy9a/v WkdyIwToi3vo4kAJu6mhyD9KSQpKqL1pnFik9fjEWUxnbZ5OVhLiF+aUPyohCm46gP84 1xumoJC+/eNEvSMs5QRoufGLS00yZEweEs6Zc/+9N5XiClfoH/NsWZAmciKjkRuNTr9P whlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=fQVqN8yNl0SPRwiwlTk1W0EDXyc3bH8NG0393Ien5DY=; b=nsMTjUu/NeO7i0nyachgC1T+QGyFW50FqQl5JeV8Kjyl6RzYRGC0KZjk6wxLW3GVtF ZLF88PsCliSKmDQ3rra3Pa+DTG4NpAcIfvbUQP5+XCvOlZjGZh7fHd/mPyi8UPmERvZR QyyYruoxwvTHISytKU5UCvVP8TsMIQZAjXvFrxBRSN+E0lbL0TOO/06Aj7NISmF6YnAF h4Kb3pgopjkS3j7s/V2xgo5YofIq1qMLGT+Pw0OIMpjJ/n0tUHlNjjP1XBA5WH0ZRKUP i4miZqzag+2I3C3wV2GS7mzZAoujEHttzzSYInNfLtLjVhpMK1j7nVVmgmgXJizKcqpl EvmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=UvUoWH6S; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id c20-20020a170902b69400b00161a06e7f53si8882080pls.292.2022.05.23.00.39.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 May 2022 00:39:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=UvUoWH6S; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0663450B3B; Sun, 22 May 2022 23:46:45 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346547AbiETHig (ORCPT + 99 others); Fri, 20 May 2022 03:38:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51434 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346552AbiETHib (ORCPT ); Fri, 20 May 2022 03:38:31 -0400 Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1847014A258 for ; Fri, 20 May 2022 00:38:30 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id c62so7561913vsc.10 for ; Fri, 20 May 2022 00:38:30 -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=fQVqN8yNl0SPRwiwlTk1W0EDXyc3bH8NG0393Ien5DY=; b=UvUoWH6St0jmkZuxkFipT30AfjesIU6zlH7xc8pdDIEKIwXxatZqiIUUzq+7mrrPuo GceM+afRrZ1hXZav7T0FaOSnRJoaHXAMPke0xyjsstcvA4pGDuHImfQ1LNR6FGIE/ciF PsOM8Z03YjkJDSJ1LQnNds/6UYhxxdTn8V+1M= 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=fQVqN8yNl0SPRwiwlTk1W0EDXyc3bH8NG0393Ien5DY=; b=ZaY4S2rvQmjWBnlIH8hLS2pQRS1yLGhbHYd/Km3cgi00+6pkJzo5BWldCYTpx8Hs6r Dlwp48bwzBGN6EbwuA5KfTtHcFPl8bRMDBD5XfY9HC+izllsQG5gh/aLY3yqxlAtM31I XES+4RH1FZBQ2LzlNRAgxIWo7wv7WRWhp8mEM2amYES01dkq1iR1LeMSovGy7H4OOL1K I3e0HLufSfscCudvo24cp1jfk8BNJ5QyTCxy6FfMwToR33zqgE9/cDTT9+pf9Pp7PvCK kTqVs4SDMBSG9SFV1oEpZFxtbhVbKB/zdG1cT3qkvlZqo1DMsF8FrJqegmBDPpKmJEEC BvfA== X-Gm-Message-State: AOAM533pymMXs+SaZFPi71kqs9lCIeFF+w4onrBeBlsFUvSyYe/SNsR2 REHpQbJWjbU3LFzP4YJSIDhZKzVeAZr7XKhYjRp0mw== X-Received: by 2002:a05:6102:1008:b0:335:e260:9ff1 with SMTP id q8-20020a056102100800b00335e2609ff1mr3597099vsp.32.1653032309031; Fri, 20 May 2022 00:38:29 -0700 (PDT) MIME-Version: 1.0 References: <20220517082650.2005840-1-hsinyi@chromium.org> <20220517082650.2005840-4-hsinyi@chromium.org> In-Reply-To: From: Hsin-Yi Wang Date: Fri, 20 May 2022 15:38:03 +0800 Message-ID: Subject: Re: [PATCH v2 3/3] squashfs: implement readahead To: Phillip Lougher Cc: Matthew Wilcox , 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-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 20, 2022 at 11:02 AM Phillip Lougher wrote: > > On 19/05/2022 09:09, Hsin-Yi Wang wrote: > > On Tue, May 17, 2022 at 4:28 PM Hsin-Yi Wang wrote: > >> > >> Implement readahead callback for squashfs. It will read datablocks > >> which cover pages in readahead request. For a few cases it will > >> not mark page as uptodate, including: > >> - file end is 0. > >> - zero filled blocks. > >> - current batch of pages isn't in the same datablock or not enough in a > >> datablock. > >> Otherwise pages will be marked as uptodate. The unhandled pages will be > >> updated by readpage later. > >> > >> Suggested-by: Matthew Wilcox > >> Signed-off-by: Hsin-Yi Wang > >> Reported-by: Matthew Wilcox > >> Reported-by: Phillip Lougher > >> Reported-by: Xiongwei Song > >> --- > >> v1->v2: remove unused check on readahead_expand(). > >> v1: https://lore.kernel.org/lkml/20220516105100.1412740-3-hsinyi@chromium.org/ > >> --- > > > > Hi Phillip and Matthew, > > > > Regarding the performance issue of this patch, I saw a possible > > performance gain if we only read the first block instead of reading > > until nr_pages == 0. > > > > To be more clear, apply the following diff (Please ignore the skipping > > of nr_pages check first. This is a demonstration of "only read and > > update the first block per readahead call"): > > > > diff --git a/fs/squashfs/file.c b/fs/squashfs/file.c > > index aad6823f0615..c52f7c4a7cfe 100644 > > --- a/fs/squashfs/file.c > > +++ b/fs/squashfs/file.c > > @@ -524,10 +524,8 @@ static void squashfs_readahead(struct > > readahead_control *ractl) > > if (!actor) > > goto out; > > > > - for (;;) { > > + { > > nr_pages = __readahead_batch(ractl, pages, max_pages); > > - if (!nr_pages) > > - break; > > > > if (readahead_pos(ractl) >= i_size_read(inode) || > > nr_pages < max_pages) > > > > > > All the performance numbers: > > 1. original: 39s > > 2. revert "mm: put readahead pages in cache earlier": 2.8s > > 3. v2 of this patch: 2.7s > > 4. v2 of this patch and apply the diff: 1.8s > > > > In my testing data, normally it reads and updates 1~2 blocks per > > readahead call. The change might not make sense since the performance > > improvement may only happen in certain cases. > > What do you think? Or is the performance of the current patch > > considered reasonable? > > It entirely depends on where the speed improvement comes from. > > From experience, the speed improvement is probably worthwhile, > and probably isn't gained at the expense of worse performance > on other work-loads. > > But this is a guestimate, based on the fact timings 2 and 3 > (2.8s v 2.7s) are almost identical. Which implies the v2 > patch isn't now doing any more work than the previous > baseline before the "mm: put readahead pages in cache earlier" > patch (*). > > As such the speed improvement must be coming from increased > parallelism. Such as moving from serially reading the > readahead blocks to parallel reading. > Thanks for the idea. I checked this by offlining other cores until only one core exists. Removing loops still results in less time. But after counting the #traces lines in squashfs_read_data(): If we remove the for loop (timings 4), the logs are less: 2.3K lines, while v2 (timings 3) has 3.7K (other timings are also around 3.7K), so removing loop doesn't look right. I think v2 should be fine considering the slightly to none regression compared to before. Hi Matthew, what do you think? Do you have other comments? If not, should I send a v3 to change Xiongwei Song's email address or can you help modify it? Thanks > But, without looking at any trace output, that is just a > guestimate. > > Phillip > > (*) multiply decompressing the same blocks, which > is the cause of the performance regression. > > > > Thanks. > > > > testing env: > > - arm64 on kernel 5.10 > > - data: ~ 300K pack file contains some android files > > > >> fs/squashfs/file.c | 77 +++++++++++++++++++++++++++++++++++++++++++++- > >> 1 file changed, 76 insertions(+), 1 deletion(-) > >> > >> diff --git a/fs/squashfs/file.c b/fs/squashfs/file.c > >> index a8e495d8eb86..e10a55c5b1eb 100644 > >> --- a/fs/squashfs/file.c > >> +++ b/fs/squashfs/file.c > >> @@ -39,6 +39,7 @@ > >> #include "squashfs_fs_sb.h" > >> #include "squashfs_fs_i.h" > >> #include "squashfs.h" > >> +#include "page_actor.h" > >> > >> /* > >> * Locate cache slot in range [offset, index] for specified inode. If > >> @@ -495,7 +496,81 @@ static int squashfs_read_folio(struct file *file, struct folio *folio) > >> return 0; > >> } > >> > >> +static void squashfs_readahead(struct readahead_control *ractl) > >> +{ > >> + struct inode *inode = ractl->mapping->host; > >> + struct squashfs_sb_info *msblk = inode->i_sb->s_fs_info; > >> + size_t mask = (1UL << msblk->block_log) - 1; > >> + size_t shift = msblk->block_log - PAGE_SHIFT; > >> + 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 (file_end == 0) > >> + return; > >> + > >> + pages = kmalloc_array(max_pages, sizeof(void *), GFP_KERNEL); > >> + if (!pages) > >> + return; > >> + > >> + actor = squashfs_page_actor_init_special(pages, max_pages, 0); > >> + if (!actor) > >> + goto out; > >> + > >> + for (;;) { > >> + nr_pages = __readahead_batch(ractl, pages, max_pages); > >> + if (!nr_pages) > >> + break; > >> + > >> + if (readahead_pos(ractl) >= i_size_read(inode) || > >> + nr_pages < max_pages) > >> + goto skip_pages; > >> + > >> + index = pages[0]->index >> shift; > >> + if ((pages[nr_pages - 1]->index >> shift) != index) > >> + goto skip_pages; > >> + > >> + bsize = read_blocklist(inode, index, &block); > >> + if (bsize == 0) > >> + goto skip_pages; > >> + > >> + res = squashfs_read_data(inode->i_sb, block, bsize, NULL, > >> + actor); > >> + > >> + if (res >= 0) > >> + for (i = 0; i < nr_pages; i++) > >> + SetPageUptodate(pages[i]); > >> + > >> + for (i = 0; i < nr_pages; i++) { > >> + unlock_page(pages[i]); > >> + put_page(pages[i]); > >> + } > >> + } > >> + > >> + kfree(actor); > >> + kfree(pages); > >> + return; > >> + > >> +skip_pages: > >> + for (i = 0; i < nr_pages; i++) { > >> + unlock_page(pages[i]); > >> + put_page(pages[i]); > >> + } > >> + > >> + kfree(actor); > >> +out: > >> + kfree(pages); > >> +} > >> > >> const struct address_space_operations squashfs_aops = { > >> - .read_folio = squashfs_read_folio > >> + .read_folio = squashfs_read_folio, > >> + .readahead = squashfs_readahead > >> }; > >> -- > >> 2.36.0.550.gb090851708-goog > >> >