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 83E69C433F5 for ; Mon, 16 May 2022 09:00:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD6A16B0071; Mon, 16 May 2022 05:00:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C5F806B0072; Mon, 16 May 2022 05:00:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD8B88D0001; Mon, 16 May 2022 05:00:58 -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 944596B0071 for ; Mon, 16 May 2022 05:00:58 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5BA22204E3 for ; Mon, 16 May 2022 09:00:58 +0000 (UTC) X-FDA: 79471011396.06.19F0DDC Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by imf07.hostedemail.com (Postfix) with ESMTP id 3EDAD400C0 for ; Mon, 16 May 2022 09:00:50 +0000 (UTC) Received: by mail-pf1-f174.google.com with SMTP id p12so13512439pfn.0 for ; Mon, 16 May 2022 02:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gdVjxgGAUOr835ntJBTft1RSai/v/LcM8u9/SZwWadE=; b=dzp51Xu6l+Dhsb5uPzrYVSMU7B9MaRnn/DV7Pn7cnfa8eeSdCIx0KF4Kwxi9um8PsW i8nudYF8+4QkisvoqKhIIxsNAGCKlL2el3grPE25pfUXD39/L8kzGO38/59IBYGeqouQ ttGBijsMHgDwgVxUOxORzw7wx5P1aknnyBruIgoeZOXGO4gjETN92ZXOJqQitwWrDhYp QgPDtg4NeLVpsjgINf55cmt6qbqnUREJ2RK+1VCqrsCx+K9CMFcWaSRZShTKJ9wutubI Pn6OUq3VHjIK8BeLPzPN8+3W2knTbi/SqZhcm+/nbX8Ya6kb6oHQ1uCff2STS+VjeXql Kfog== 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=gdVjxgGAUOr835ntJBTft1RSai/v/LcM8u9/SZwWadE=; b=j7mlEF96iPFlUXsdQzG9a+DTleWhhKyAQOTfJtB1v94RsQGJj4w9Y0W/uWwdvAxx6h 6gnIov6R2XYbpUpOVp/yaOR4GO2JzgwVF9S8kpj7fFLAF44yA5Sizc0XGJpCdcrZ4nf7 DjBnPrFDPVs0LRBKq0vDXlPOFGmW0ecKz1PtOEk9tmZit/IHP/k3p2Xk8nlJpMJrXv8x I/H9vKRv4TkDIjd+xKnWnREYDDu6vgOuMe2s5EGwGZNoykIpkJkhQHB2QNTQlcEaD5k1 OXVDxj16hxk0yiMW4ZbhLB2i9Sn9CmQaJibSSX20Tr4ptZAEOsKdhpv0OBfemWVptnk5 dSpQ== X-Gm-Message-State: AOAM532QJFX/7qmKcUkRbu4EvnVxH/8aD89yGHnl87lj3VA7k1RZ3Vmu LPTDymwEZAmMjdrI5YRx9Ip2BN++BCGBdQBdJO4= X-Google-Smtp-Source: ABdhPJzmBSjtaEIBcVAmjI/0wOb+1hOSEVK+H9x5faN9HTOERbyMoEMzK5FVoWsQZXa9xz8hcAuha/vOO3HkQAtjuLs= X-Received: by 2002:a63:6b82:0:b0:39d:a6ce:14dc with SMTP id g124-20020a636b82000000b0039da6ce14dcmr14458200pgc.476.1652691656547; Mon, 16 May 2022 02:00:56 -0700 (PDT) MIME-Version: 1.0 References: <1f8a8009-1c05-d55c-08bd-89c5916e5240@squashfs.org.uk> In-Reply-To: From: Xiongwei Song Date: Mon, 16 May 2022 17:00:30 +0800 Message-ID: Subject: Re: squashfs performance regression and readahea To: Hsin-Yi Wang Cc: Phillip Lougher , Matthew Wilcox , Zheng Liang , Zhang Yi , Hou Tao , Miao Xie , Andrew Morton , Linus Torvalds , "Song, Xiongwei" , "linux-mm@kvack.org" , "squashfs-devel@lists.sourceforge.net" Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: s1gb4s78haocfeemdfzmtk3eiozw5ye9 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3EDAD400C0 X-Rspam-User: Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dzp51Xu6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of sxwjean@gmail.com designates 209.85.210.174 as permitted sender) smtp.mailfrom=sxwjean@gmail.com X-HE-Tag: 1652691650-969989 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: You can not just sign your signature. You ignored others' contributions. This is unacceptable. On Mon, May 16, 2022 at 4:23 PM Hsin-Yi Wang wrote: > > On Sun, May 15, 2022 at 8:55 AM Phillip Lougher wrote: > > > > On 13/05/2022 07:35, Hsin-Yi Wang wrote: > > > On Fri, May 13, 2022 at 1:33 PM Phillip Lougher wrote: > > >> > > >> 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. > > >> > > > I noticed that if nr_pages < max_pages, calling read_blocklist() will > > > have SQUASHFS errors, > > > > > > SQUASHFS error: Failed to read block 0x125ef7d: -5 > > > SQUASHFS error: zlib decompression failed, data probably corrupt > > > > > > so I did a check if nr_pages < max_pages before squashfs_read_data(), > > > just skip the remaining pages and let them be handled by readpage. > > > > > > > Yes that avoids passing the decompressor code a too small page range. > > As such extending the decompressor code isn't necessary. > > > > Testing your patch I discovered a number of cases where > > the decompressor still failed as above. > > > > This I traced to "sparse blocks", these are zero filled blocks, and > > are indicated/stored as a block length of 0 (bsize == 0). Skipping > > this sparse block and letting it be handled by readpage fixes this > > issue. > > > Ack. Thanks for testing this. > > > I also noticed a potential performance improvement. You check for > > "pages[nr_pages - 1]->index >> shift) == index" after calling > > squashfs_read_data. But this information is known before > > calling squashfs_read_data and moving the check to before > > squashfs_read_data saves the cost of doing a redundant block > > decompression. > > > After applying this, The performance becomes: > 2.73s > 2.76s > 2.73s > > Original: > 2.76s > 2.79s > 2.77s > > (The pack file is different from my previous testing in this email thread.) > > > Finally I noticed that if nr_pages grows after the __readahead_batch > > call, then the pages array and the page actor will be too small, and > > it will cause the decompressor to fail. Changing the allocation to > > max_pages fixes this. > > > Ack. > > I've added the fixes patch and previous fixes. > > I have rolled these fixes into the patch below (also attached in > > case it gets garbled). > > > > diff --git a/fs/squashfs/file.c b/fs/squashfs/file.c > > index 7cd57e0d88de..14485a7af5cf 100644 > > --- a/fs/squashfs/file.c > > +++ b/fs/squashfs/file.c > > @@ -518,13 +518,11 @@ static void squashfs_readahead(struct > > readahead_control *ractl) > > file_end == 0) > > return; > > > > - nr_pages = min(readahead_count(ractl), max_pages); > > - > > - pages = kmalloc_array(nr_pages, sizeof(void *), GFP_KERNEL); > > + pages = kmalloc_array(max_pages, sizeof(void *), GFP_KERNEL); > > if (!pages) > > return; > > > > - actor = squashfs_page_actor_init_special(pages, nr_pages, 0); > > + actor = squashfs_page_actor_init_special(pages, max_pages, 0); > > if (!actor) > > goto out; > > > > @@ -538,11 +536,18 @@ static void squashfs_readahead(struct > > readahead_control *ractl) > > 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 && (pages[nr_pages - 1]->index >> shift) == index) > > + if (res >= 0) > > for (i = 0; i < nr_pages; i++) > > SetPageUptodate(pages[i]); > > > > -- > > 2.34.1 > > > > > > > > Phillip > > > > > > >> This is important for the decompression code, because it > > >> expects each pages array entry to reference a page, which > > >> can be kmapped to an address. If an entry in the pages > > >> array is NULL, this will break. > > >> > > >> If the pages array can have holes (NULL pointers), I have > > >> written an update patch which allows the decompression code > > >> to handle these NULL pointers. > > >> > > >> If the pages array can have NULL pointers, I can send you > > >> the patch which will deal with this. > > > > > > Sure, if there are better ways to deal with this. > > > > > > Thanks. > > > > > >> > > >> Thanks > > >> > > >> Phillip > > >> > > >> > > >> > > >>> > > >>>>> > > >>>>> It's also noticed that when the crash happened, nr_pages obtained by > > >>>>> readahead_count() is 512. > > >>>>> nr_pages = readahead_count(ractl); // this line > > >>>>> > > >>>>> 2) Normal cases that won't crash: > > >>>>> [ 22.651750] Block @ 0xb3bbca6, compressed size 42172, src size 262144 > > >>>>> [ 22.653580] Block @ 0xb3c6162, compressed size 29815, src size 262144 > > >>>>> [ 22.656692] Block @ 0xb4a293f, compressed size 17484, src size 131072 > > >>>>> [ 22.666099] Block @ 0xb593881, compressed size 39742, src size 262144 > > >>>>> [ 22.668699] Block @ 0xb59d3bf, compressed size 37841, src size 262144 > > >>>>> [ 22.695739] Block @ 0x13698673, compressed size 65907, src size 131072 > > >>>>> [ 22.698619] Block @ 0x136a87e6, compressed size 3155, src size 131072 > > >>>>> [ 22.703400] Block @ 0xb1babe8, compressed size 99391, src size 131072 > > >>>>> [ 22.706288] Block @ 0x1514abc6, compressed size 4627, src size 131072 > > >>>>> > > >>>>> nr_pages are observed to be 32, 64, 256... These won't cause a crash. > > >>>>> Other values (max_pages, bsize, block...) looks normal > > >>>>> > > >>>>> I'm not sure why the crash happened, but I tried to modify the mask > > >>>>> for a bit. After modifying the mask value to below, the crash is gone > > >>>>> (nr_pages are <=256). > > >>>>> Based on my testing on a 300K pack file, there's no performance change. > > >>>>> > > >>>>> diff --git a/fs/squashfs/file.c b/fs/squashfs/file.c > > >>>>> index 20ec48cf97c5..f6d9b6f88ed9 100644 > > >>>>> --- a/fs/squashfs/file.c > > >>>>> +++ b/fs/squashfs/file.c > > >>>>> @@ -499,8 +499,8 @@ 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; > > >>>>> + size_t mask = (1UL << shift) - 1; > > >>>>> > > >>>>> > > >>>>> Any pointers are appreciated. Thanks! > > >>>> > > >>