Message ID | 0_29676200_1505871839.10311.cbgrn@bozuman.cybozu.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show
Return-Path: <linux-fsdevel-owner@kernel.org> Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 0E148601E9 for <patchwork-linux-fsdevel@patchwork.kernel.org>; Wed, 20 Sep 2017 01:45:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F0BEA28F6E for <patchwork-linux-fsdevel@patchwork.kernel.org>; Wed, 20 Sep 2017 01:45:19 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E347C28F79; Wed, 20 Sep 2017 01:45:19 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 67C9428F72 for <patchwork-linux-fsdevel@patchwork.kernel.org>; Wed, 20 Sep 2017 01:45:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751391AbdITBoF (ORCPT <rfc822;patchwork-linux-fsdevel@patchwork.kernel.org>); Tue, 19 Sep 2017 21:44:05 -0400 Received: from mail-sg2apc01on0124.outbound.protection.outlook.com ([104.47.125.124]:22425 "EHLO APC01-SG2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751000AbdITBoD (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>); Tue, 19 Sep 2017 21:44:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybozu.co.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vQ1G2Jj9o3Xiic9gBhZr6cMGw2zuAcMlth+qB8RdfZc=; b=Fp7o1m02nG9OnEKDJZ8fZC9wbYjanh/EfcGgwO4GlxCcLMDVI6CNwx/8vJkP3zkEopurS3mSU0mn/0N95RhO3+m5rrrIAspcpWViR7iGa0sASE/fSXeOEWPEJPxwNIBpxea/5jG0XBdEsA4NW+3YdvDNmoUS+7lJtD9xMqQ8FdQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=shunki-fujita@cybozu.co.jp; Received: from nat.cybozu.com (103.79.14.80) by SINPR03MB2319.apcprd03.prod.outlook.com (2a01:111:e400:a824::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 20 Sep 2017 01:43:59 +0000 Date: Wed, 20 Sep 2017 10:43:59 +0900 Subject: [RFC PATCH] fs: don't flush pagecahce when expanding block device From: Shunki Fujita <shunki-fujita@cybozu.co.jp> To: viro@zeniv.linux.org.uk, andrew.patterson@hpe.com Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org X-Mailer: Cybozu(R) Garoon(R) Message-ID: <0_29676200_1505871839.10311.cbgrn@bozuman.cybozu.com> mime-version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Originating-IP: [103.79.14.80] X-ClientProxiedBy: KAXPR01CA0005.jpnprd01.prod.outlook.com (2603:1096:402:19::15) To SINPR03MB2319.apcprd03.prod.outlook.com (2a01:111:e400:a824::28) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 91983e79-71a6-4dc6-f05d-08d4ffc910c1 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SINPR03MB2319; X-Microsoft-Exchange-Diagnostics: 1; SINPR03MB2319; 3:yVdCpk1pEHR6Wy54p34uG2lfxSMDv5Io0BOgATg2f5i4O00bhgVaob626T6SMxWSjU22MiURwn9iRlwhQVNKXzCspH7bpoJkK/XTwUB8YzgUBL6jHOp/3xohWc6mDMRq+Yox8aiKDtVIezmUGJcvKuTBoiFmg4orxAcYocIlpIwACihTnS5ffXYQVO2FvavMdEqxa3l+REdz2+lisvxWo0nf1Q5lpaa+KYeGPNuMWr6jCDX3x0x8UwPbH+ttM6E2; 25:g3fCSDM2aGVv/uUP1M0Dlq1p7kIaxhVRjJZMhuvKOULi7fl0npFHMqxAswvTE2I4DpUqUt9VKV/ES/Qv9Ks09dn6J1eAx25Nsnq3KQlHiEqlHea7N0LTGH5sftcuzOKHL5NyyW8TOQMnlbJ96L2Jb4DV4HQG5vD3JUIoZAhWwjJa/nB//d1T/OYnDLcHRZlBjxCvGT+hHS6TLOx2U96BfY7Sxgq6S7hS22x69n5pld5aldsSaQDIrcO5+Y1mVfQp/8sjeXgx0OpUrAG85BF88zXuOp5FJuGPKOyH0IooJO9FJzzN6loiDyuirhboW0CT//rWWxbRzbybQnmIc/B9hA==; 31:smgSjKYGHkk2bQgu/Zs1gY4J9B/ut5N3HGoyiIC29TOOljFkRtIykSuQF5ZW3vYdpuJGdxiddn7l/0L3QPjcHTPR/unXzusHdb7StdtQjm3t8/UlsMeNYmkM4fyQCbxOZOARH5k3Pa+f6kciHrrWSMqPYQLdOkrmL6NLcOHHAbUYPEAgqEim9v41syeECeohOhzR4Mta1VlazTYAyW0nbHej17pfl8xrL4YiaF78dN0= X-MS-TrafficTypeDiagnostic: SINPR03MB2319: X-Microsoft-Exchange-Diagnostics: 1; SINPR03MB2319; 20:+f2zGYVSL9SAN8YfKAsJRCmP7LSNzBVZHmvZZg3PaQ0Hq53gu8lpY8YhWm8qVDySeKArm3yvz4fdMnrJ4Qi5QO8TNn5+bpGahFwaA01+iaeFDAhXzQY2UBaZSINW6RWSDluTY2sjBZ69EUWLPOaELObKM248/yaJK4UeJCiM3410NSlMx5hdiDUin1u39k3c72n2iwWzMJ1wvLsgWnM0AIWUSgAIK4U8DbWxDaciuFV6upQfruUVjCd77+DKUfL1lcBHlRDBWXeGEZ2HaAyY9SL6pNbXCVgC0Kf3yIEUWmBHQiaVVz/d1O2M2Zk4HjGRJLZznarCov8j/UizR/xh/1JFF4TnXrrV2MZh/O3huPxa/UWHUT7EWXB2RaoJBpMGcxOm+2/EZbZO82oMycKf9KmBmKQ57R3hI2pho316KD+xMj2VmDQuQ7gfgVEy2F/4TXm8hSYEZtxxtj3Z0yCIUioDxV0T9GZlDQSwj5O5JHUr4nabDe4JzurTjVKk/Brn; 4:HXAqr+jNffoGTCSbTjNKflJ3sYDlO9njJEDBRoCeK439vFXot1C20NUJvYQYgouqAFT6VAnEwkx4LK6kLZDhDNbfIRuZL4jPTPhmJm8giFE+nQgWiFTbUBuf/JORTXao0ynouEvyV4/QeOw1cTFRIHoCJwXjyvUNe8YDFem/pw6qpoUXEyyz6Z8WaEoEbUEzpG0jHsioHwLN1k6LjU3pdepuZoVfQc60+xzENDOS6QsRMkvzVbdSsQqksvi0d/0t4FMr6St6iRo9UrXwV3OO3j6X2RbhTSyD34ydlqiv47A= X-Exchange-Antispam-Report-Test: UriScan:(166708455590820); X-Microsoft-Antispam-PRVS: <SINPR03MB23190589E08E72CCA6362156DE610@SINPR03MB2319.apcprd03.prod.outlook.com> X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SINPR03MB2319; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SINPR03MB2319; X-Forefront-PRVS: 04362AC73B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(199003)(189002)(101416001)(25786009)(69596002)(47776003)(6116002)(3846002)(7736002)(68736007)(305945005)(66066001)(189998001)(33646002)(53416004)(42882006)(5660300001)(50986999)(106356001)(97736004)(50466002)(966005)(316002)(16526017)(81166006)(81156014)(6486002)(230700001)(53936002)(86362001)(6306002)(6506006)(9686003)(50226002)(4326008)(74482002)(23736002)(2906002)(105586002)(8676002)(478600001)(8936002)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:SINPR03MB2319; H:nat.cybozu.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cybozu.co.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-2022-jp?B?MTtTSU5QUjAzTUIyMzE5OzIzOlNOUUdaYVJlb3ZaQXEvN1dZcm5mTzBa?= =?iso-2022-jp?B?WExUMWNhZ1hZRUxNY051K2Y0SXpHc2c3Yk92Z2FlekJ6T010b3RUOWxL?= =?iso-2022-jp?B?ajdWUnpTSkVDamwrS2Q4aUczQUxMV2ZCN2ZpUDN3ZCsydS9UeXI2bXBQ?= =?iso-2022-jp?B?QXQ4SDVISi9XbzR0RnRXZlU1Wld2VXJRSHB4Z1FDOWdZa0tBZnd6cy9P?= =?iso-2022-jp?B?dmZyVWtKaTRtZWhWUEVQeEJwSzFadHN1TThrYVlCN1dydHgrSzdVRlRj?= =?iso-2022-jp?B?M3RlellkdVROSmxTcWNnZVRxdTJwQ1ZvZEZucXluVzluVHI4UDBHUkpa?= =?iso-2022-jp?B?T1JIWjVQWEtQbWdZbVcycFdad2tqbE05T2tqOEFKTVcvYUFBaFEwTE9z?= =?iso-2022-jp?B?UkJoamJlN3lRVCtSQ1Vpbjlab1Q3Y3EwK3V3VkFXMS9YYWxtWjNJem1E?= =?iso-2022-jp?B?QXdGWkM2aDNES0pjZTlSMlhBR0JYdjVONVpvbTZ6L2xDdXl3cWVOWS9V?= =?iso-2022-jp?B?aUIyb2dzVnZPb0tmNWYva0NZTFVVYjlzRWZwN1lWa0lHdjZ6RVFkem1Z?= =?iso-2022-jp?B?SmVzMVFmOHBuSlk0TnRpRzl6S09qQS9wTFZNVGNxcURiSk80dmxVWFJ2?= =?iso-2022-jp?B?M1N4R01ZZDZSV2drN1hxMGxEVzhDQ0RBR1B4dStSWnRjemhNMWRsaTE3?= =?iso-2022-jp?B?amVzdlM2UDM5QlRnVkE5VlI3Zm9hYVRDU1FEZUU1eVpWT09VWE9kR21P?= =?iso-2022-jp?B?OUxvOGhqdk9Ud01CY3dKcldWNnljeTd4ditnSGtKSlVvbVExRkJWbXYr?= =?iso-2022-jp?B?N0ZHazB3S0V0MEpwVnMxME1mQUM3YTRjaDNhK3NFYlZMUFFzS0hQdXpu?= =?iso-2022-jp?B?NFhhT1J1QUlqU2UvUWcwRjNzZ0FZWEwvS1l0SFVNT1hoQWcvQ3B0MXdI?= =?iso-2022-jp?B?TU5ibE5JdEJ6aTlKYUlZV21WTDAxL3oyandPczlwVmxhUG5Zc1hRcmk0?= =?iso-2022-jp?B?WmRKOUdsZEJjaEpQK0MyQnlKNWtjeW4rNWtuVVBXSElKelE1QUF1Z2tp?= =?iso-2022-jp?B?Y2F5YXI2eTVKYnEzTFhNUW1XYmk2cHBqcXBVMWFCK291NVRCb0RuNG5X?= =?iso-2022-jp?B?aFlQdGZXTmZGeWZ3S0lFOXZuYllsVitiaFdKSSs4VU5lNmxaRWJ3akIz?= =?iso-2022-jp?B?K3BHN2ZMZ0JEQ1pab0NtYW9vdU1NQW9CSWFSWGdVTVZWTitKV0lHMUEz?= =?iso-2022-jp?B?VmFTL29kZ21STSs4QVBTUk5Db1lVVnlhc0RLVFVlUjBITXB1VjVsYU9w?= =?iso-2022-jp?B?Nyt1a3VPWTdmcjFxeEcxV3VkNGpVSWFYSUZBRE5GSEZueXFmbzFSZWJv?= =?iso-2022-jp?B?L0ZER095dmlzWUxLNUxyZHA0MVVZSTdUMFBFbnI3eXkvMk1ENUNudXBi?= =?iso-2022-jp?B?MmNiZExORmRjSW1FeXllVU5SQVlFeFlNK1V2OTl6WFJZWDVReFZyME9I?= =?iso-2022-jp?B?aDdzSGZPZHpuOGY0VTRMOXQ1T2tuM1QwN05FTldkZC84WlBDY0p5RVd4?= =?iso-2022-jp?B?d21nOCtLSS9SSk5RMGR5OFdqU3hwT1o3aThGVG5WK3drTksxZz09?= X-Microsoft-Exchange-Diagnostics: 1; SINPR03MB2319; 6:sAt/cGP8yD9qCTnnpqU7q6Kgz8kDb0BwZ68kKsLi+AN4z+8PGFvxR4yzs1+7OPjdgSOgpSLv76kIbaHge36neWMFK6QhyesLdcDNbujo9X/4b5GQBnW40ac0ThO1i0GcBnbkAPBHIzxP21rCZ94i0sW4a2UGtVgnhOqFnVgwZGre/LkKmQJE7jyGb0rfGuo5pPlAa6oe8109TR1WUWeMNkoA+VBOudX93H9jx2awWnAGZVv2nI5FFCDH71ye5Nc6ke+g/0JUonED3PqfQozhHDTqZ9cBYknluVmKFf9tXS73tQn2eLxUFHEvxeiEZrJb2rWvU5+nNG6ytUYPoHSxHw==; 5:06nPyKyS+vqTJ7KOkSSIeL4Sws3BPg/ah8OQNKP6iqYFIOQvJXuEE3G9hLIYECi1tnWVBmMKm++JoxRSpGANlEBBq+GkCaMpL16h5e3GbcdAvYDknHSoCg8mIJRj9meXwlhc6Ovt4uPf9bX2qq+IrQ==; 24:zYkjbo/VgFj3sFC9f2HeHe9t+Jx3xUyOVF7AtwQTxRqxz4DT3tzDOKTaRvtC5hkKavbUWKNC6lxMyfAT/BnZTFa+fE5687G2pH4m85LgZoo=; 7:zO1Uu29jJP/sCcXmFGdB3FCjFpo9RC4IcrGhLS+CE3yUj1/6BJUyKwdnP+mnk55yrXrdhQH41XDyMbNQH6pPP7e2Cxv3F2XMEuvJ0MdcfOy6vTBeoilsEJJdJqPoWIgyM4D+2kx1aGZyEYNgsVZEKAg5/W7Nofqh4b+Jw6GuLGD4YlnD0GoMWH25RwHYla1cgmyKgkg7jGco/MQ37eZfuBkW+sA36RUS/+QqQXu3IqI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cybozu.co.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2017 01:43:59.5893 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3761f390-05f7-4386-9a0b-b6806c13b841 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SINPR03MB2319 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: <linux-fsdevel.vger.kernel.org> X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP |
diff --git a/fs/block_dev.c b/fs/block_dev.c index 44d4a1e..d17603c 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -1078,7 +1078,14 @@ void check_disk_size_change(struct gendisk *disk, struct block_device *bdev) "%s: detected capacity change from %lld to %lld\n", name, bdev_size, disk_size); i_size_write(bdev->bd_inode, disk_size); - flush_disk(bdev, false); + if (bdev_size > disk_size) { + flush_disk(bdev, false); + } else { + if (!bdev->bd_disk) + return; + if (disk_part_scan_enabled(bdev->bd_disk)) + bdev->bd_invalidated = 1; + } } } EXPORT_SYMBOL(check_disk_size_change);
I have a trouble with my service and have two questions and an RFC patch. I run a web service as follows. - Its data is on a multipath device which size is sometimes grown. - It uses many page caches - It's response time is usually about 0.2 s. When I grow the multipath device, kernel flushes this device's all caches and the response time becomes 20 s, 100 times slower than usual. IIUC, this flushing seems not to be necessary because of the reason described later. However, looking at the comments of the past commit, it seems that the buffer cache is intentionally flushed not only in shrinking case but also growing case. (cf. https://github.com/torvalds/linux/commit/608aeef17a91747d6303de4df5e2c2e6899a95e8) I have two questions about this: 1. I interpret that the following situation is concerned, is my understanding correct? <Situation> On a 10 GB device, if calls occur as shown in the table below that CPU0 shrink device to 5 GB and CPU1 grows device to 15 GB, struct gendisk and struct block_device are already the same size at (*). So in this case, the cache is not flushed in shrinking. (cf. https://github.com/torvalds/linux/blob/608aeef17a91747d6303de4df5e2c2e6899a95e8/fs/block_dev.c#L897) CPU0 (shrink) CPU1 (grow) ============================= set_capacity() set_capacity() revalidate_disk() revalidate_disk() ...(*) 2. If 1 is yes, the above mentioned situation seems not to happen since all pairs of set_capacity() and revalidate_disk() are protected by some kind of lock mechanism. If it's correct, how about avoiding the performance problem which I mentioned by the following patch? Thanks, Shunki --- It's not necessary to flush caches about a device which is under growing. Signed-off-by: Shunki Fujita <shunki-fujita@cybozu.co.jp> --- fs/block_dev.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)