Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965301AbeAJOYX convert rfc822-to-8bit (ORCPT + 1 other); Wed, 10 Jan 2018 09:24:23 -0500 Received: from mail-oln040092069025.outbound.protection.outlook.com ([40.92.69.25]:63584 "EHLO EUR02-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S964790AbeAJOYU (ORCPT ); Wed, 10 Jan 2018 09:24:20 -0500 From: Chiara Bruschi To: Jens Axboe CC: "linux-block@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "paolo.valente@linaro.org" , "federico@willer.it" Subject: Re: [PATCH] block, bfq: fix occurrences of request finish method's old name Thread-Topic: [PATCH] block, bfq: fix occurrences of request finish method's old name Thread-Index: AQHTeBxUL5Zh9y2IKkiE4tV4VgCTpKNtRYyO Date: Wed, 10 Jan 2018 14:24:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:7BF9F532CED435CC7CD941C4CBC9D31D830B380AD0C09339BF5D10824E565793;UpperCasedChecksum:050A1BDCA257FEA4B578DD4AD0107565720D44EBF6414F7FCBD2476A2274062A;SizeAsReceived:7369;Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [BWPr7chZdRbBtPaMMcF/KWCcbxm+zjkgpI5oTm8WLNM=] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;AM5EUR02HT119;6:+0XMzEMbn9Q7L+Jv5cmWt1V7h1jRk/GcMlV0pabBtURnPnzfP9CM5WjpsF5Q3pGKAH7e1rjnNZpVVXmMP502YJCGlyJg5NoG4/KXBROWOxU3F/YhPCeKfwk3Q70xaO3cn9+7x+zd1D9lPa2zkVa776YyWiXBQqwmeVs1iAdFv1lcc8D1IALrw0bIKNRYsD170orOlDf+7SPVh+E1T/GM1/kTSZdOQ867tZCCWZVANREpoJkqeL7Tcc67loulEStWbco4C8liBdIX1EkFJYHFY/Uhys7QF84MQcICgn/HO63p5zwXwqwVs05niLvyg897ZbjaT3vl0uqiSBkoygudUh3oB/mNBxiR7/OMnEb+sr8=;5:OCMGfugJNPeiEN/Ci3HBwhZHIQQL4JEa8S3Gh6hHelhhjkSNqGscfSp2tQaZI7G6iLdRdsapVhHYqRyfaMk0uARrdUtUJlf07s++zj0qCgepy/bJmV92m2vHHvyCj8G8A1vZx70Mpww4BctQWp3327zWeWoulPpNwf2uR2RoBoY=;24:cndcquC9+ti4BgJew1rkpYe7QY0c/+b7VHFTZ81AL1Xc4CntxYBgXduTnZekj0EogrEIIehz+gbIjfITKBGXRBi2z/CzW9Ha3iCal+Btsp8=;7:JVOYTpM6Q1sXaoIebcBVrl88RmxTZWRllTsdlThxfz5Elh3/t39QQeOekn2CqxDO6IuaiGfjO+c6kXu+MqJ38ZpNlIIt/f7V9Txt7YDcXdUCZcFyHj6qCJQsytl7MTgwElOleYRVtmhRaXUhdCfKeK/NfbkPS1aTbNUtqjMq6N+6r2Pxky2gapXL1iy65n0iDmerc+DB/SfN8Obz61/+5GwiLJrsbUoj9dsqMNpDsSHdOX/QjODKzTAbylBJf2Ne x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020052)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045);SRVR:AM5EUR02HT119; x-ms-traffictypediagnostic: AM5EUR02HT119: x-ms-office365-filtering-correlation-id: d514eb51-adae-4926-3d62-08d55835d5bc x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(444000031);SRVR:AM5EUR02HT119;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:AM5EUR02HT119; x-forefront-prvs: 0548586081 x-forefront-antispam-report: SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:AM5EUR02HT119;H:DB5PR09MB0263.eurprd09.prod.outlook.com;FPR:;SPF:None;LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d514eb51-adae-4926-3d62-08d55835d5bc X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2018 14:24:18.4562 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR02HT119 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hi Jens, have you had time to look into this? Thank you, Chiara Bruschi On 12/18/17 5:21 PM, Chiara Bruschi wrote: Commit '7b9e93616399' ("blk-mq-sched: unify request finished methods") changed the old name of current bfq_finish_request method, but left it unchanged elsewhere in the code (related comments, part of function name bfq_put_rq_priv_body). This commit fixes all occurrences of the old name of this method by changing them into the current name. Fixes: 7b9e93616399 ("blk-mq-sched: unify request finished methods") Reviewed-by: Paolo Valente Signed-off-by: Federico Motta Signed-off-by: Chiara Bruschi --- ?block/bfq-iosched.c | 26 +++++++++++++------------- ?1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index bcb6d21..6da7f71 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -3630,8 +3630,8 @@ static struct request *__bfq_dispatch_request(struct blk_mq_hw_ctx *hctx) ???????????????? } ? ???????????????? /* -??????????????? * We exploit the put_rq_private hook to decrement -??????????????? * rq_in_driver, but put_rq_private will not be +??????????????? * We exploit the bfq_finish_request hook to decrement +??????????????? * rq_in_driver, but bfq_finish_request will not be ????????????????? * invoked on this request. So, to avoid unbalance, ????????????????? * just start this request, without incrementing ????????????????? * rq_in_driver. As a negative consequence, @@ -3640,14 +3640,14 @@ static struct request *__bfq_dispatch_request(struct blk_mq_hw_ctx *hctx) ????????????????? * bfq_schedule_dispatch to be invoked uselessly. ????????????????? * ????????????????? * As for implementing an exact solution, the -??????????????? * put_request hook, if defined, is probably invoked -??????????????? * also on this request. So, by exploiting this hook, -??????????????? * we could 1) increment rq_in_driver here, and 2) -??????????????? * decrement it in put_request. Such a solution would -??????????????? * let the value of the counter be always accurate, -??????????????? * but it would entail using an extra interface -??????????????? * function. This cost seems higher than the benefit, -??????????????? * being the frequency of non-elevator-private +??????????????? * bfq_finish_request hook, if defined, is probably +??????????????? * invoked also on this request. So, by exploiting +??????????????? * this hook, we could 1) increment rq_in_driver here, +??????????????? * and 2) decrement it in bfq_finish_request. Such a +??????????????? * solution would let the value of the counter be +??????????????? * always accurate, but it would entail using an extra +??????????????? * interface function. This cost seems higher than the +??????????????? * benefit, being the frequency of non-elevator-private ????????????????? * requests very low. ????????????????? */ ???????????????? goto start_rq; @@ -4482,7 +4482,7 @@ static void bfq_completed_request(struct bfq_queue *bfqq, struct bfq_data *bfqd) ???????????????? bfq_schedule_dispatch(bfqd); ?} ? -static void bfq_put_rq_priv_body(struct bfq_queue *bfqq) +static void bfq_finish_request_body(struct bfq_queue *bfqq) ?{ ???????? bfqq->allocated--; ? @@ -4512,7 +4512,7 @@ static void bfq_finish_request(struct request *rq) ???????????????? spin_lock_irqsave(&bfqd->lock, flags); ? ???????????????? bfq_completed_request(bfqq, bfqd); -?????????????? bfq_put_rq_priv_body(bfqq); +?????????????? bfq_finish_request_body(bfqq); ? ???????????????? spin_unlock_irqrestore(&bfqd->lock, flags); ???????? } else { @@ -4533,7 +4533,7 @@ static void bfq_finish_request(struct request *rq) ???????????????????????? bfqg_stats_update_io_remove(bfqq_group(bfqq), ???????????????????????????????????????????????????? rq->cmd_flags); ???????????????? } -?????????????? bfq_put_rq_priv_body(bfqq); +?????????????? bfq_finish_request_body(bfqq); ???????? } ? ???????? rq->elv.priv[0] = NULL; -- 2.1.4