From patchwork Wed Mar 7 23:40:52 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Theodore Ts'o X-Patchwork-Id: 145362 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id CDAB7B6EEA for ; Thu, 8 Mar 2012 10:40:59 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754748Ab2CGXk4 (ORCPT ); Wed, 7 Mar 2012 18:40:56 -0500 Received: from li9-11.members.linode.com ([67.18.176.11]:46040 "EHLO test.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752569Ab2CGXkz (ORCPT ); Wed, 7 Mar 2012 18:40:55 -0500 Received: from root (helo=tytso-glaptop.cam.corp.google.com) by test.thunk.org with local-esmtp (Exim 4.69) (envelope-from ) id 1S5QTV-0001f6-To; Wed, 07 Mar 2012 23:40:53 +0000 Received: from tytso by tytso-glaptop.cam.corp.google.com with local (Exim 4.71) (envelope-from ) id 1S5QTU-0005Cc-Kl; Wed, 07 Mar 2012 18:40:52 -0500 Date: Wed, 07 Mar 2012 18:40:52 -0500 Message-Id: To: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org Subject: [PATCH, RFC] Don't do page stablization if !CONFIG_BLKDEV_INTEGRITY From: "Theodore Ts'o" Full-Name: Theodore Ts'o Phone: (781) 391-3464 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on test.thunk.org); SAEximRunCond expanded to false Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org We've recently discovered a workload at Google where the page stablization patches (specifically commit 0e499890c1f: ext4: wait for writeback to complete while making pages writable) resulted in a **major** performance regression. As in, kernel threads that were writing to log files were getting hit by up to 2 seconds stalls, which very badly hurt a particular application. Reverting this commit fixed the performance regression. The main reason for the page stablizatoin patches was for DIF/DIX support, right? So I'm wondering if we should just disable the calls to wait_on_page_writeback if CONFIG_BLKDEV_INTEGRITY is not defined. i.e., something like this. What do people think? I have a feeling this is going to be very controversial.... - Ted ext4: Disable page stablization if DIF/DIX not enabled Requiring processes which are writing to files which are under writeback until the writeback is complete can result in massive performance hits. This is especially true if writes are being throttled due to I/O cgroup limits and the application is running on an especially busy server. If CONFIG_BLKDEV_INTEGRITY is not enabled, disable page stablization, since that's the main case where this is needed, and page stablization can be very painful. Signed-off-by: "Theodore Ts'o" --- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/buffer.c b/fs/buffer.c index 1a30db7..d25c60f 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -2333,7 +2333,9 @@ int __block_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf, ret = -EAGAIN; goto out_unlock; } +#ifdef CONFIG_BLKDEV_INTEGRITY wait_on_page_writeback(page); +#endif return 0; out_unlock: unlock_page(page); diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 5f8081c..01f86c5 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4638,8 +4638,10 @@ int ext4_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf) if (page_has_buffers(page)) { if (!walk_page_buffers(NULL, page_buffers(page), 0, len, NULL, ext4_bh_unmapped)) { +#ifdef CONFIG_BLKDEV_INTEGRITY /* Wait so that we don't change page under IO */ wait_on_page_writeback(page); +#endif ret = VM_FAULT_LOCKED; goto out; }