From patchwork Mon Apr 9 06:16:02 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "jianchao.wang" X-Patchwork-Id: 10330637 Return-Path: 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 117546020F for ; Mon, 9 Apr 2018 06:16:04 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 04B88288FD for ; Mon, 9 Apr 2018 06:16:04 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EBE2228A64; Mon, 9 Apr 2018 06:16:03 +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=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY 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 6AC42288FD for ; Mon, 9 Apr 2018 06:16:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752280AbeDIGPc (ORCPT ); Mon, 9 Apr 2018 02:15:32 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:53416 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752264AbeDIGPa (ORCPT ); Mon, 9 Apr 2018 02:15:30 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3964CJx037802; Mon, 9 Apr 2018 06:15:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id; s=corp-2017-10-26; bh=1QOYH0swyE5LuTRK/e77aaLDZD2ny3spnuwu4KgUFMA=; b=HoycAxXQXpM1AaBepLo44ise1sKL+tsnhApjgGs4A3Qbv9kn0JGhU+6IrzU3jIY/kgb/ ySDArFz6gL1J1TAKawY0V1wt6/xZJEHv7dc9BBEqzsL0r0T3RZmGXw4Ww/ghhYKpFEX1 KWsldbSQWRRHONoyevvBmSqTqjacl86r/Jb1QLpIovCTjQAPJ2iQY1NWYtP566WGza52 vsxwHTRHjRDKu8pqmMKBdYlEkTBix2zTs2/RFVeU1DsiX+ZMwOkMViaHALvs3uECNamV 85IusSyoPzLHUKKBlt758sudH8icRe8pLTUVpIFfZoFxYBSyVzBTyo7SMNgWRYvLqjfR gA== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2h6ne73sdg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 09 Apr 2018 06:15:27 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w396FQrp018026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Apr 2018 06:15:26 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w396FPKm013300; Mon, 9 Apr 2018 06:15:26 GMT Received: from will-ThinkCentre-M910s.cn.oracle.com (/10.182.69.123) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 08 Apr 2018 23:15:25 -0700 From: Jianchao Wang To: axboe@kernel.dk, shli@fb.com Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] blk-throttle: only update last_low_overflow_time when LIMIT_MAX Date: Mon, 9 Apr 2018 14:16:02 +0800 Message-Id: <1523254562-2006-1-git-send-email-jianchao.w.wang@oracle.com> X-Mailer: git-send-email 2.7.4 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8857 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=878 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804090068 Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Currently, last_low_overflow_time will be updated whenever bios are throttled and queued. This is true when LIMIT_MAX, but not for LIMIT_LOW. what last_low_overflow_time indicates is dispatching not submitting. When LIMIT_LOW, the dispatch bps/iops should never be above the low limit, we should not update last_low_overflow_time at the moment. Otherwise, it will be hard to upgrade limit_index when there is always bios to be submitted. Signed-off-by: Jianchao Wang --- block/blk-throttle.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/block/blk-throttle.c b/block/blk-throttle.c index 851aa16..b5ba845 100644 --- a/block/blk-throttle.c +++ b/block/blk-throttle.c @@ -2214,7 +2214,8 @@ bool blk_throtl_bio(struct request_queue *q, struct blkcg_gq *blkg, /* if above limits, break to queue */ if (!tg_may_dispatch(tg, bio, NULL)) { - tg->last_low_overflow_time[rw] = jiffies; + if (td->limit_index == LIMIT_MAX) + tg->last_low_overflow_time[rw] = jiffies; if (throtl_can_upgrade(td, tg)) { throtl_upgrade_state(td); goto again; @@ -2258,7 +2259,8 @@ bool blk_throtl_bio(struct request_queue *q, struct blkcg_gq *blkg, tg->io_disp[rw], tg_iops_limit(tg, rw), sq->nr_queued[READ], sq->nr_queued[WRITE]); - tg->last_low_overflow_time[rw] = jiffies; + if (td->limit_index == LIMIT_MAX) + tg->last_low_overflow_time[rw] = jiffies; td->nr_queued[rw]++; throtl_add_bio_tg(bio, qn, tg);