From patchwork Sun Apr 12 11:33:12 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Boaz Harrosh X-Patchwork-Id: 6202781 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 1BE57BF4A6 for ; Sun, 12 Apr 2015 11:33:33 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2F49E201EC for ; Sun, 12 Apr 2015 11:33:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2D3DE20270 for ; Sun, 12 Apr 2015 11:33:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751612AbbDLLdV (ORCPT ); Sun, 12 Apr 2015 07:33:21 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:33762 "EHLO mail-wg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751509AbbDLLdP (ORCPT ); Sun, 12 Apr 2015 07:33:15 -0400 Received: by wgin8 with SMTP id n8so55289671wgi.0 for ; Sun, 12 Apr 2015 04:33:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6BMZILSCtfLjcnCFPFL4f2i5nlJJ19IwBl2w6IzkF9U=; b=iZjRi0GKCNLDljpegR4shtywuelzrNhuQt5CdaGnIL919AjgYbY3X5fR2TIw1Tu63N 30SyO+D8bVdvglrmIeAuAJCm1+kn+cXCgGxRGGNPLazGIOCL6LuTPOKDbyQ3Fbpq/zFV /+O7DIkBabTTNzo7v7SRew4JAo/qBaqKPKOV8pdbkB686cEqcAQGMtImEFQxPnoHGQui 4geoU+TZz1CxQ9ua3bROGAzHxuSpq4xBnkjowiVvsEBlouDYWJ/DqMFmC9S4YK/5KUz4 4/GR5j7MdjkGhnzpNgx227ZnElf6RdFXi+Xc9oSHLfaS0fZ3iueAKBtrutP4enizS/Cx 7UQw== X-Gm-Message-State: ALoCoQnvMoNaQWhqPN6nKnhAVppbWYr7sjETVX1+OUgkaiyH/7PvfjvU4k1Z/KsxOHW/1TnUzqFE X-Received: by 10.194.184.10 with SMTP id eq10mr18728628wjc.147.1428838394636; Sun, 12 Apr 2015 04:33:14 -0700 (PDT) Received: from [10.0.0.5] ([207.232.55.62]) by mx.google.com with ESMTPSA id kr5sm6651471wjc.1.2015.04.12.04.33.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Apr 2015 04:33:13 -0700 (PDT) Message-ID: <552A57F8.7020002@plexistor.com> Date: Sun, 12 Apr 2015 14:33:12 +0300 From: Boaz Harrosh User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Zhao Lei , 'Christoph Hellwig' CC: linux-fsdevel@vger.kernel.org, 'Jan Kara' , 'Jens Axboe' , 'LKML' Subject: Re: Regression caused by using node_to_bdi() References: <016d01d07380$fc37fc40$f4a7f4c0$@cn.fujitsu.com> In-Reply-To: <016d01d07380$fc37fc40$f4a7f4c0$@cn.fujitsu.com> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 04/10/2015 02:25 PM, Zhao Lei wrote: > Hi, Christoph Hellwig > > resend: + cc lkml, linux-fsdevel > > Since there is no response for my last mail, I worry that some problem in > the mail system, please allow me to resend it. > > I found regression in v4.0-rc1 caused by this patch: > Author: Christoph Hellwig > Date: Wed Jan 14 10:42:36 2015 +0100 > fs: export inode_to_bdi and use it in favor of mapping->backing_dev_info > <> > Result is following: > v3.19-rc1: testcnt=40 average=135.677 range=[132.460,139.130] stdev=1.610 cv=1.19% > v4.0-rc1: testcnt=40 average=130.970 range=[127.980,132.050] stdev=1.012 cv=0.77% > > Then I bisect above case between v3.19-rc1 and v4.0-rc1, and found > this patch caused the regresstion. > > Maybe it is because kernel need more time to call node_to_bdi(), > compared with "using inode->i_mapping->backing_dev_info directly" in > old code. > > Is there some way to speed up it(inline, or some access some variant > in struct directly, ...)? > Christoph hi Both node_to_bdi() and sb_is_blkdev_sb() (and I_BDEV() && blk_get_backing_dev_info()) Are an exported function calls. Can we not make blockdev_superblock->s_bdi == NULL, and then optimize-out the call to sb_is_blkdev_sb() to only that case. Something like: --- -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" 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/fs-writeback.c b/fs/fs-writeback.c index 32a8bbd..e0375e1 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -78,7 +78,7 @@ int writeback_in_progress(struct backing_dev_info *bdi) } EXPORT_SYMBOL(writeback_in_progress); -struct backing_dev_info *inode_to_bdi(struct inode *inode) +struct backing_dev_info *__inode_to_bdi(struct inode *inode) { struct super_block *sb; @@ -92,7 +92,7 @@ struct backing_dev_info *inode_to_bdi(struct inode *inode) #endif return sb->s_bdi; } -EXPORT_SYMBOL_GPL(inode_to_bdi); +EXPORT_SYMBOL_GPL(__inode_to_bdi); static inline struct inode *wb_inode(struct list_head *head) { diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h index aff923a..7d172f5 100644 --- a/include/linux/backing-dev.h +++ b/include/linux/backing-dev.h @@ -107,7 +107,16 @@ struct backing_dev_info { #endif }; -struct backing_dev_info *inode_to_bdi(struct inode *inode); +struct backing_dev_info *__inode_to_bdi(struct inode *inode); + +static inline +struct backing_dev_info *inode_to_bdi(struct inode *inode) +{ + if (!inode || !inode->i_sb) + return __inode_to_bdi(inode); + + return inode->i_sb->s_bdi; +} int __must_check bdi_init(struct backing_dev_info *bdi); void bdi_destroy(struct backing_dev_info *bdi);