Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3384155imu; Fri, 18 Jan 2019 09:27:05 -0800 (PST) X-Google-Smtp-Source: ALg8bN7Ir/pOkpFuPNuqd1RN6mRodnR258no3p+rsKZW42GHeOl9pRVH9yx1wnbqadbZrnvAsZpN X-Received: by 2002:a63:f658:: with SMTP id u24mr18686517pgj.267.1547832425167; Fri, 18 Jan 2019 09:27:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547832425; cv=none; d=google.com; s=arc-20160816; b=RSyXfYhbL2CuMjY70+aBXu+Bkm1KAvJ7Q1luiVbvvaSp67emg+R6KVAGM/VstagvJj l2tLY11DGQlt3avRoERKomeIcap2E5hbQxCtBojC+WQb7E97P6JmetkHx+3cMAtzC2Ex CkIUCfaPeBvTQc548ZXjqcHjGHgUxYX7d6BDQatFfzqdS32UoSUDeVri8ncMKx49PS8T iKlXNKLYiGKUCTI5ip24cgrnoTQQd5MkToDbgfj9/gsLckM5kc+l12B2sy3rh8kRDJ/p a4lj/LDiMQFngUbIy0rjyFDzvl9n660e0DR6bOWBRqpvrGWcHa3Po78Y1diHCSf6YwWl T+aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=LdL19VvuwiQZZQ+oXgplGPEqEZFpfJRXauSkt/RaFu0=; b=bX3VbsokrU46WFcPounUDfHZ08N/nhEnMf6tqeCPenkXAO90ObMErTF7nxdEjf++q9 on3vkUMZZV/15OmZYN7fQ9/j21xGWp/KGxrcHIP648T9i0wD8cRg3Fmi1NtDEC/a8ASF u6Oj2LpQO22YcMBFGW3gK5m9ZWcQofl3dzo0C9PqdcrWCl1ECNp1nWEmYUKDQuQPqdZU wrUXixupJSKHVNmx/y7bhqy4UNIHJaGxs6+faLWpcBdWu04NG2mjroB9UY1nyVdGWNZn uINavmTuM7kfe4Y/yu3AmhQlrhPadnMfYdJ8cfPQ5bP1ZE5W/YHQAReUuNvlJGw/Ifpz zV7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=dw8SHWcc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b11si5319664pgb.536.2019.01.18.09.26.46; Fri, 18 Jan 2019 09:27:05 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=dw8SHWcc; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728173AbfARRYh (ORCPT + 99 others); Fri, 18 Jan 2019 12:24:37 -0500 Received: from mail-wr1-f66.google.com ([209.85.221.66]:38372 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727553AbfARRYg (ORCPT ); Fri, 18 Jan 2019 12:24:36 -0500 Received: by mail-wr1-f66.google.com with SMTP id v13so16013018wrw.5 for ; Fri, 18 Jan 2019 09:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LdL19VvuwiQZZQ+oXgplGPEqEZFpfJRXauSkt/RaFu0=; b=dw8SHWcckTunJdkNoFnXE9/1uLqJo1Ul0ji/kVYmUGizIdZsq5AtLEVZKRZQmTU6q4 Oyle3luglOWNJhxQVbllJcj7mzXylQlO+0uFFT1bAt5XJ2X7BtYk+bOws30Z0VECps1h /fxxUUxgJ1vl9h/rOz7i090tg2UzohxHLBq1I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LdL19VvuwiQZZQ+oXgplGPEqEZFpfJRXauSkt/RaFu0=; b=guyrMOD3kqk5gNTPCKvWE1xKaWBb13I5d6GELMNIZ4sXgcFYLAM0B9mLZClrn87/My YZcvVPaa2lqKML2vOnid/HKMR6qchXSVDXxMX59HnTAijqSDUljFaybwiokcuFX+fQqh Y+Yl+PP5f+6yR+iadJffD0+dALObUrt4+0yn7GD+iuu+32lntlJoCnqy69dNFa+dcAFq dlz2MTfQpFGd8b30wCI2ACf93N+QdwTSoLRqR4TG53L97wzgM4RubQYPd5v4MFi3k0Be 7u1nUMXkb3V46xqQ3RHLdqK1LMS6L4c2DLDtkS2JqiDfKLrqFf6BsXvlwU/7T5vus8Lg 9XrA== X-Gm-Message-State: AJcUukdzyO43/glhw8VvvP+d+2hltra5ZFb0ANNxlvwFA3GVX/C7VWpv +3mXLRUNDj8eQ4icq1i/z5ECXw== X-Received: by 2002:adf:eec9:: with SMTP id a9mr17041395wrp.242.1547832274351; Fri, 18 Jan 2019 09:24:34 -0800 (PST) Received: from [192.168.43.112] ([37.162.17.17]) by smtp.gmail.com with ESMTPSA id c129sm29970547wma.48.2019.01.18.09.24.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Jan 2019 09:24:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: [PATCH BUGFIX RFC 0/2] reverting two commits causing freezes From: Paolo Valente In-Reply-To: Date: Fri, 18 Jan 2019 18:24:31 +0100 Cc: linux-block , linux-kernel , Ulf Hansson , Linus Walleij , Mark Brown , 'Paolo Valente' via bfq-iosched , oleksandr@natalenko.name, hurikhan77+bko@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190118115219.63576-1-paolo.valente@linaro.org> To: Jens Axboe X-Mailer: Apple Mail (2.3445.102.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Il giorno 18 gen 2019, alle ore 14:35, Jens Axboe ha = scritto: >=20 > On 1/18/19 4:52 AM, Paolo Valente wrote: >> Hi Jens, >> a user reported a warning, followed by freezes, in case he increases >> nr_requests to more than 64 [1]. After reproducing the issues, I >> reverted the commit f0635b8a416e ("bfq: calculate shallow depths at >> init time"), plus the related commit bd7d4ef6a4c9 ("bfq-iosched: >> remove unused variable"). The problem went away. >=20 > For reverts, please put the justification into the actual revert > commit. With this series, if applied as-is, we'd have two patches > in the tree that just says "revert X" without any hint as to why > that was done. >=20 I forget to say explicitly that these patches were meant only to give you and anybody else something concrete to test and check. With me you're as safe as houses, in terms of amount of comments in final patches :) >> Maybe the assumption in commit f0635b8a416e ("bfq: calculate shallow >> depths at init time") does not hold true? >=20 > It apparently doesn't! But let's try and figure this out instead of > blindly reverting it. Totally agree. > OK, I think I see it. For the sched_tags > case, when we grow the requests, we allocate a new set. Hence any > old cache would be stale at that point. >=20 ok > How about something like this? It still keeps the code of having > to update this out of the hot IO path, and only calls it when we > actually change the depths. >=20 Looks rather clean and efficient. > Totally untested... >=20 It seems to work here too. Thanks, Paolo >=20 > diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c > index cd307767a134..b09589915667 100644 > --- a/block/bfq-iosched.c > +++ b/block/bfq-iosched.c > @@ -5342,7 +5342,7 @@ static unsigned int bfq_update_depths(struct = bfq_data *bfqd, > return min_shallow; > } >=20 > -static int bfq_init_hctx(struct blk_mq_hw_ctx *hctx, unsigned int = index) > +static void bfq_depth_updated(struct blk_mq_hw_ctx *hctx) > { > struct bfq_data *bfqd =3D hctx->queue->elevator->elevator_data; > struct blk_mq_tags *tags =3D hctx->sched_tags; > @@ -5350,6 +5350,11 @@ static int bfq_init_hctx(struct blk_mq_hw_ctx = *hctx, unsigned int index) >=20 > min_shallow =3D bfq_update_depths(bfqd, &tags->bitmap_tags); > sbitmap_queue_min_shallow_depth(&tags->bitmap_tags, = min_shallow); > +} > + > +static int bfq_init_hctx(struct blk_mq_hw_ctx *hctx, unsigned int = index) > +{ > + bfq_depth_updated(hctx); > return 0; > } >=20 > @@ -5772,6 +5777,7 @@ static struct elevator_type iosched_bfq_mq =3D { > .requests_merged =3D bfq_requests_merged, > .request_merged =3D bfq_request_merged, > .has_work =3D bfq_has_work, > + .depth_updated =3D bfq_depth_updated, > .init_hctx =3D bfq_init_hctx, > .init_sched =3D bfq_init_queue, > .exit_sched =3D bfq_exit_queue, > diff --git a/block/blk-mq.c b/block/blk-mq.c > index 3ba37b9e15e9..a047b297ade5 100644 > --- a/block/blk-mq.c > +++ b/block/blk-mq.c > @@ -3101,6 +3101,8 @@ int blk_mq_update_nr_requests(struct = request_queue *q, unsigned int nr) > } > if (ret) > break; > + if (q->elevator && q->elevator->type->ops.depth_updated) > + q->elevator->type->ops.depth_updated(hctx); > } >=20 > if (!ret) > diff --git a/include/linux/elevator.h b/include/linux/elevator.h > index 2e9e2763bf47..6e8bc53740f0 100644 > --- a/include/linux/elevator.h > +++ b/include/linux/elevator.h > @@ -31,6 +31,7 @@ struct elevator_mq_ops { > void (*exit_sched)(struct elevator_queue *); > int (*init_hctx)(struct blk_mq_hw_ctx *, unsigned int); > void (*exit_hctx)(struct blk_mq_hw_ctx *, unsigned int); > + void (*depth_updated)(struct blk_mq_hw_ctx *); >=20 > bool (*allow_merge)(struct request_queue *, struct request *, = struct bio *); > bool (*bio_merge)(struct blk_mq_hw_ctx *, struct bio *); >=20 > --=20 > Jens Axboe >=20