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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B29B8C25B0E for ; Tue, 16 Aug 2022 20:46:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237025AbiHPUqI (ORCPT ); Tue, 16 Aug 2022 16:46:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57658 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229524AbiHPUqH (ORCPT ); Tue, 16 Aug 2022 16:46:07 -0400 Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45D3A88DEE; Tue, 16 Aug 2022 13:46:04 -0700 (PDT) Received: from [192.168.1.138] ([37.4.248.80]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MO9r5-1o0Dxc2Fk9-00OTr7; Tue, 16 Aug 2022 22:45:49 +0200 Message-ID: Date: Tue, 16 Aug 2022 22:45:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [Regression] ext4: changes to mb_optimize_scan cause issues on Raspberry Pi Content-Language: en-US To: Jan Kara Cc: linux-ext4@vger.kernel.org, Ojaswin Mujoo , Harshad Shirwadkar , Theodore Ts'o , Ritesh Harjani , linux-fsdevel@vger.kernel.org, Linux Kernel Mailing List , Geetika.Moolchandani1@ibm.com, regressions@lists.linux.dev, Florian Fainelli References: <0d81a7c2-46b7-6010-62a4-3e6cfc1628d6@i2se.com> <20220728100055.efbvaudwp3ofolpi@quack3> <64b7899f-d84d-93de-f9c5-49538bd080d0@i2se.com> <20220816093421.ok26tcyvf6bm3ngy@quack3> From: Stefan Wahren In-Reply-To: <20220816093421.ok26tcyvf6bm3ngy@quack3> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:QATVIxUIzO4XNP67B+8HP4QQNAu7SDUyzpY148ZnYDJfs7tnRBJ P4nHE8TnbMh+WgAS4rs/lgc7XTshocNV1OpZ44YQvy18WcgxRaLBk+kobb43uc74GoOFyUp gR19howWA1OqDL8Aq7YNa5EhexZE8b5NFYrK0PM4hMG49wBDM/sICkgNrOWNn1soXhDp+O8 TqJAbNdm7pr3HJsnooNqA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Dra9fYDHkDA=:LvzOC2xL//tX1hAXYwU6nP Xf8alCLDOQOQVZ1lFlSGB67f41WkgrfgssPP1f4+UaS3E3TG4cGF0tsXcRWiFUN4G9iS0FMah PfPmyvrCtS0hTE2PxsxyoA1jZttLzTnGWoDD72bDtMalXNh1BJFx5BL/JHLMMg3C9T2xCgBO+ EaeBMnfhvgUCiVIuJC+xJJ19ULU0VIr/x+NclzX0Awh8QgGj0ImzqqW6lPtkTOwcjplQGXpXV qJFD/Nyy9NrT9TcSNnL2urdRZh0Sdt79CcFlGiqyLGHsEPHQly2MOS1R980Pfwz9dk/vwgBx3 8PM0SILNrkSW57E/ebKxgzhzoWcg9e+4CP4PT8gKy0z+owfBgbry7NQLrni4dLDgiRa+/KCGJ S4k8aA9an1czUvCWKOvTghF0ItEE65m3HK7p+9LZn4gYRCzdRwjtlnnfJl/NjzV5dilVZHEip vuNDwZr+qi3FJdRwvayJafSpWBulsOcNVXpxnmQmQFWcYKGue2BSPk6bVefWqWYKTqSQrmybU LSzgd0IRYtVKNnYn7HvQ91MwBCDATC4NMyvdboc0p6smOgcwuixLPz23NBibReFoPTuMfvES0 qELwYqY1vOAGwZshxk9S4yHJsC5digby73z7VshICqFAvOEoUuI8C0631KS+oQ8yIKJ69a3ye 8euDAUwAqvZMis6VzjlfpFpuQvvd3DrYyUIV/0ACn9+XcaOSx3E1okAxgw7RrGIVEFDXi+f+x zuITU/bdK06q5H2UVfcfhxbuIaXn960VSqOyEgTHQQwhHBfaLtvHmZZdZoc= Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hi Jan, Am 16.08.22 um 11:34 schrieb Jan Kara: > Hi Stefan! > So this is interesting. We can see the card is 100% busy. The IO submitted > to the card is formed by small requests - 18-38 KB per request - and each > request takes 0.3-0.5s to complete. So the resulting throughput is horrible > - only tens of KB/s. Also we can see there are many IOs queued for the > device in parallel (aqu-sz columnt). This does not look like load I would > expect to be generated by download of a large file from the web. > > You have mentioned in previous emails that with dd(1) you can do couple > MB/s writing to this card which is far more than these tens of KB/s. So the > file download must be doing something which really destroys the IO pattern > (and with mb_optimize_scan=0 ext4 happened to be better dealing with it and > generating better IO pattern). Can you perhaps strace the process doing the > download (or perhaps strace -f the whole rpi-update process) so that we can > see how does the load generated on the filesystem look like? Thanks! i didn't create the strace yet, but i looked at the source of rpi-update. At the end the download phase is a curl call to download a tar archive and pipe it directly to tar. You can find the content list of the tar file here: https://raw.githubusercontent.com/lategoodbye/mb_optimize_scan_regress/main/rpi-firmware-tar-content-list.txt Best regards > > Honza