Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1721109imm; Tue, 22 May 2018 08:19:23 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpWOBjA3NcQXDa2DNRGsczQqV94ECVon0BHGNNUAlcMd5jH58X2Zl1z2Bg5dWZBJlUxPPf0 X-Received: by 2002:a63:7c04:: with SMTP id x4-v6mr19213863pgc.67.1527002363477; Tue, 22 May 2018 08:19:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527002363; cv=none; d=google.com; s=arc-20160816; b=ezr3i2ApPOmfS8jOeITmoKYXimdOE43LoQ/JoLY5sPSoU9e7O+L1IWhXdO1OjgstDE cf5aL7sw/td9BZQ+Ax2TP7yirNOZ+Vj+EjdP0GpreuQUkyS+/5uTjtqj7Azq7gJAXEgW gwu6f76/MmEWdZCEOrHDE9QyH2nirUh6xcnpABz/P9dZSW2QclCl1akpOtA9vtTUdO7l ZUhgdNJPNQgyxnIiURUrSjQFAXEcMxlQxsT7yNMtbmBkVoMnZdsi5Tx7vvETipzX9MIC RjJyMY5aReV7c0rX0fHUqdFiKhTZSi5SBxvV3gx/pacy9LCs55dUPUQpspMDvoEsw/Rj guYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:mime-version:user-agent:date:message-id:cc:to :subject:from:dkim-signature:arc-authentication-results; bh=a4OGo1Y8qf4hEUL/L94ub7dseaMJZs3UFoHy7jYPliM=; b=rUgbrBOLYSf3oC5zRKzjB1g170UWmEoFS11hdqmPdYrivkIEIeN4muYDIuqecdTt62 sxyhHuU5ANYfgeDwk+fWWMmYjHsi0/qhW0+inPyRsAk1JmF16dgwo6JjdGIoVxxLqxsD 5jrv4PcSPNWV2CZGP745OvAiVx0M2wtBjjpzb4gPyVFJBXd1QNfbayu67JCUFzOyOw+s Wkf05oLiHjsBaTS83YvhZtPrzYiuZ+Yt4ETVzxuhUaeHH+Tx3bRLvoNeUR8rGVjGUmcH XEzUfLih/eeqJ8f68bRBVMGFj9RobUifX+ZdxM1Dr2OGyF1zbTuzmS2DFruWGy1kzXy+ lDYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=Yzs8cO/R; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t3-v6si16049317ply.192.2018.05.22.08.19.09; Tue, 22 May 2018 08:19:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=Yzs8cO/R; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751732AbeEVPRZ (ORCPT + 99 others); Tue, 22 May 2018 11:17:25 -0400 Received: from lelnx193.ext.ti.com ([198.47.27.77]:64098 "EHLO lelnx193.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751287AbeEVPQ6 (ORCPT ); Tue, 22 May 2018 11:16:58 -0400 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by lelnx193.ext.ti.com (8.15.1/8.15.1) with ESMTP id w4MFGrGD000655; Tue, 22 May 2018 10:16:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1527002213; bh=a4OGo1Y8qf4hEUL/L94ub7dseaMJZs3UFoHy7jYPliM=; h=From:Subject:To:CC:Date; b=Yzs8cO/RVmdTssLt0MeczZUvb4cq/pHQbSGE8A4PWjG+glKqb4yHkgl5KVSyt0tXr SqJoEHsLQ8avfpdWWYbEaO5270iOVaZy80ZcNQh9pVZUbGqR2ZLvR83jB2G4BcITAq pbsJiPer/6fXHxVyHH8XoSAhlxIxXxUnMPUEKtnU= Received: from DFLE102.ent.ti.com (dfle102.ent.ti.com [10.64.6.23]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id w4MFGrd5002198; Tue, 22 May 2018 10:16:53 -0500 Received: from DFLE112.ent.ti.com (10.64.6.33) by DFLE102.ent.ti.com (10.64.6.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 22 May 2018 10:16:53 -0500 Received: from dflp33.itg.ti.com (10.64.6.16) by DFLE112.ent.ti.com (10.64.6.33) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1466.3 via Frontend Transport; Tue, 22 May 2018 10:16:53 -0500 Received: from [172.24.190.215] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp33.itg.ti.com (8.14.3/8.13.8) with ESMTP id w4MFGoNN022574; Tue, 22 May 2018 10:16:51 -0500 From: Faiz Abbas Subject: mmc filesystem performance decreased on the first write after filesystem creation To: "linux-kernel@vger.kernel.org" , linux-omap , linux-mmc , linux-block CC: Christoph Hellwig , Ulf Hansson , Jens Axboe Message-ID: Date: Tue, 22 May 2018 20:48:31 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I am debugging a performance reduction in ext2 filesystems on an mmc device in TI's am335x evm board. I see that the performance is reduced on the first write after making a new filesystem using mkfs.ext2 on one of the mmc partitions. The performance comes back to normal after the first write. commands used: => umount /dev/mmcblk1p2 => mkfs.ext2 -F /dev/mmcblk1p2 => mount -t ext2 -o async /dev/mmcblk1p2 /mnt/partition_mmc => dd if=/dev/urandom of=/dev/shm/srctest_file_mmc_1184 bs=1M count=10 => ./filesystem_tests -write -src_file /dev/shm/srctest_file_mmc_1184 -srcfile_size 10 -file /mnt/partition_mmc/test_file_1184 -buffer_size 102400 -file_size 100 -performance The filesystem_tests write utility reads from the file generated at /dev/shm/srctest_file_mmc_1184, memory maps the file to a buffer, and then writes it into the newly created /mnt/partition_mmc in multiples of buffer_size while measuring write performance. See here for the implementation of filesystem_tests write utility: http://arago-project.org/git/projects/?p=test-automation/ltp-ddt.git;a=blob;f=testcases/ddt/filesystem_test_suite/src/testcases/st_filesystem_write_to_file.c;h=80e8e244d7eaa9f0dbd9b21ea705445156c36bef;hb=f7fc06c290333ce08a7d4fba104eee0f0f1d942b Complete log with multiple calls to filesystem_tests: https://pastebin.ubuntu.com/p/BckmTJpqPv/ Notice that the first run of filesystem_tests has a lower throughput reported. I was able to bisect the issue to this commit: 5d1429fead5b (mmc: remove the discard_zeroes_data flag) I would assume that after this flag is removed, the filesystem creation command would explicitly write zeroes to the device which might explain the performance fall. However, then the mkfs.ext2 command itself should take more time rather than the first file write after that. It would be nice if someone could help me understand why this is happening. Thanks for your help. Regards, Faiz