Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755593AbbGFMcf (ORCPT ); Mon, 6 Jul 2015 08:32:35 -0400 Received: from mailout4.samsung.com ([203.254.224.34]:34043 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754698AbbGFMcb (ORCPT ); Mon, 6 Jul 2015 08:32:31 -0400 X-AuditID: cbfee61a-f79516d000006302-6b-559a755d1624 From: Chao Yu To: Jaegeuk Kim Cc: linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: [PATCH 2/2] f2fs: enhance multithread performance Date: Mon, 06 Jul 2015 20:31:49 +0800 Message-id: <004901d0b7e7$d2c0e650$7842b2f0$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AdC32nbR9JwQEEvYR7eiZkjQW/+60w== Content-language: zh-cn X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsVy+t9jAd3Y0lmhBvcmqlo8WT+L2eLSIneL y7vmsDkwe2xa1cnmsXvBZyaPz5vkApijuGxSUnMyy1KL9O0SuDLWrl/IXvBKqOLDhIWsDYyz +bsYOTkkBEwk2jYsYoawxSQu3FvPBmILCSxilFhxP7KLkQvIfsUosez5IbAiNgEVieUd/5lA bBEg+9Ciy+wgNrOAh0Rjx3dWEFtYwErixrzVYDUsAqoSC/5+B+vlFbCU6N+6mwnCFpT4Mfke C0SvlsT6nceZIGx5ic1r3kIdpCCx4+xrRohdehKHTiyAqheX2HjkFssERoFZSEbNQjJqFpJR s5C0LGBkWcUomlqQXFCclJ5rqFecmFtcmpeul5yfu4kRHL7PpHYwrmywOMQowMGoxMO7oW5m qBBrYllxZe4hRgkOZiUR3mqfWaFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeU/m+4QKCaQnlqRm p6YWpBbBZJk4OKUaGJe///hLz+nD0/s2z2b7vCw/eZx1wtXGXSFz47a7KIUaJd5dmJVwdg9v 9oODed2CGmmnMxXuFTf683U+8w0u5Dk660/V9rXWsd/mf0nSXRsx/6Dy9C3fL6pc5Gb/9fPb CychtipjFaUMyTmr4y/N03WqM74V9UZw9dHGrqz6ya/djRSWX1vStFyJpTgj0VCLuag4EQCR GjfOWwIAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2581 Lines: 79 In ->writepages, we use writepages mutex lock to serialize all block address allocation and page submitting pairs from different inodes. This method makes our delayed dirty pages of one inode being written continously as many as possible. But there is one problem that we did not submit current cached bio in protection region of writepages mutex lock, so there is a small chance that we submit the one of other thread's as below, resulting in splitting more bios. thread 1 thread 2 ->writepages lock(writepages) ->write_cache_pages unlock(writepages) lock(writepages) ->write_cache_pages ->f2fs_submit_merged_bio ->writepage unlock(writepages) fs_mark-6535 [002] .... 2242.270230: f2fs_submit_write_bio: dev = (1,0), WRITE_SYNC, DATA, sector = 5766152, size = 524288 fs_mark-6536 [000] .... 2242.270361: f2fs_submit_write_bio: dev = (1,0), WRITE_SYNC, DATA, sector = 5767176, size = 4096 fs_mark-6536 [000] .... 2242.270370: f2fs_submit_write_bio: dev = (1,0), WRITE_SYNC, NODE, sector = 8138112, size = 4096 fs_mark-6535 [002] .... 2242.270776: f2fs_submit_write_bio: dev = (1,0), WRITE_SYNC, DATA, sector = 5767184, size = 516096 This may really increase time of block layer works, and may cause larger IO lantency. This patch moves the submitting operation into region of writepages mutex lock to avoid bio splits when concurrently writebacking is intensive. my test environment: virtual machine, intel cpu i5 2500, 8GB size memory, 4GB size ramdisk time fs_mark -t 16 -L 1 -s 524288 -S 1 -d /mnt/f2fs/ before: real 0m4.244s user 0m0.088s sys 0m12.336s after: real 0m3.822s user 0m0.072s sys 0m10.760s Signed-off-by: Chao Yu --- fs/f2fs/data.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 6cf75d3..37a2632 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -1703,11 +1703,10 @@ static int f2fs_write_data_pages(struct address_space *mapping, locked = true; } ret = write_cache_pages(mapping, wbc, __f2fs_writepage, mapping); + f2fs_submit_merged_bio(sbi, DATA, WRITE); if (locked) mutex_unlock(&sbi->writepages); - f2fs_submit_merged_bio(sbi, DATA, WRITE); - remove_dirty_dir_inode(inode); wbc->nr_to_write = max((long)0, wbc->nr_to_write - diff); -- 2.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/