From: Jens Axboe <axboe@kernel.dk>
To: Paolo Valente <paolo.valente@linaro.org>, Tejun Heo <tj@kernel.org>
Cc: Fabio Checconi <fchecconi@gmail.com>,
Arianna Avanzini <avanzini.arianna@gmail.com>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
ulf.hansson@linaro.org, linus.walleij@linaro.org,
broonie@kernel.org,
Mauro Andreolini <mauro.andreolini@unimore.it>
Subject: Re: [PATCH RFC 10/14] block, bfq: add Early Queue Merge (EQM)
Date: Tue, 7 Mar 2017 10:44:00 -0700 [thread overview]
Message-ID: <d37a7169-f279-8244-19f8-440dc1490893@kernel.dk> (raw)
In-Reply-To: <20170304160131.57366-11-paolo.valente@linaro.org>
On 03/04/2017 09:01 AM, Paolo Valente wrote:
> @@ -560,6 +600,15 @@ struct bfq_data {
> struct bfq_io_cq *bio_bic;
> /* bfqq associated with the task issuing current bio for merging */
> struct bfq_queue *bio_bfqq;
> +
> + /*
> + * io context to put right after bfqd->lock is released. This
> + * filed is used to perform put_io_context, when needed, to
> + * after the scheduler lock has been released, and thus
> + * prevent an ioc->lock from being possibly taken while the
> + * scheduler lock is being held.
> + */
> + struct io_context *ioc_to_put;
> };
The logic around this is nasty, effectively you end up having locking
around sections of code instea of structures, which is never a good
idea.
The helper functions for unlocking and dropping the ioc add to the mess
as well.
Can't we simply pass back a pointer to an ioc to free? That should be
possible, given that we must have grabbed the bfqd lock ourselves
further up in the call chain. So we _know_ that we'll drop it later on.
If that wasn't the case, the existing logic wouldn't work.
--
Jens Axboe
next prev parent reply other threads:[~2017-03-07 19:34 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-04 16:01 [PATCH RFC 00/14] Add the BFQ I/O Scheduler to blk-mq Paolo Valente
2017-03-04 16:01 ` [PATCH RFC 01/14] block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler Paolo Valente
2017-03-05 15:16 ` Jens Axboe
2017-03-05 16:02 ` Paolo Valente
2017-03-06 20:46 ` Jens Axboe
2017-03-14 11:28 ` Paolo Valente
2017-03-06 19:40 ` Bart Van Assche
2017-03-14 14:18 ` Paolo Valente
2017-03-18 12:08 ` Paolo Valente
2017-03-18 15:24 ` Bart Van Assche
2017-03-19 11:45 ` Paolo Valente
2017-03-07 23:22 ` Jens Axboe
2017-03-18 12:41 ` Paolo Valente
2017-03-04 16:01 ` [PATCH RFC 02/14] block, bfq: add full hierarchical scheduling and cgroups support Paolo Valente
2017-03-04 16:01 ` [PATCH RFC 03/14] block, bfq: improve throughput boosting Paolo Valente
2017-03-04 16:01 ` [PATCH RFC 04/14] block, bfq: modify the peak-rate estimator Paolo Valente
2017-03-07 0:47 ` Bart Van Assche
2017-03-04 16:01 ` [PATCH RFC 05/14] block, bfq: add more fairness with writes and slow processes Paolo Valente
2017-03-04 16:01 ` [PATCH RFC 06/14] block, bfq: improve responsiveness Paolo Valente
2017-03-04 16:01 ` [PATCH RFC 07/14] block, bfq: reduce I/O latency for soft real-time applications Paolo Valente
2017-03-04 16:01 ` [PATCH RFC 08/14] block, bfq: preserve a low latency also with NCQ-capable drives Paolo Valente
2017-03-04 16:01 ` [PATCH RFC 09/14] block, bfq: reduce latency during request-pool saturation Paolo Valente
2017-03-04 16:01 ` [PATCH RFC 10/14] block, bfq: add Early Queue Merge (EQM) Paolo Valente
2017-03-07 17:44 ` Jens Axboe [this message]
2017-03-15 12:01 ` Paolo Valente
2017-03-15 15:47 ` Jens Axboe
2017-03-15 16:30 ` Jens Axboe
2017-03-15 16:59 ` Paolo Valente
2017-03-15 21:00 ` Jens Axboe
2017-03-18 10:33 ` Paolo Valente
2017-03-15 16:56 ` Jens Axboe
2017-03-15 17:02 ` Paolo Valente
2017-03-15 21:01 ` Jens Axboe
2017-03-04 16:01 ` [PATCH RFC 11/14] block, bfq: reduce idling only in symmetric scenarios Paolo Valente
2017-03-04 16:01 ` [PATCH RFC 12/14] block, bfq: boost the throughput on NCQ-capable flash-based devices Paolo Valente
2017-03-04 16:01 ` [PATCH RFC 13/14] block, bfq: boost the throughput with random I/O on NCQ-capable HDDs Paolo Valente
2017-03-07 0:54 ` Bart Van Assche
2017-03-14 14:12 ` Paolo Valente
2017-03-04 16:01 ` [PATCH RFC 14/14] block, bfq: handle bursts of queue activations Paolo Valente
2017-03-06 7:43 ` [PATCH RFC 00/14] Add the BFQ I/O Scheduler to blk-mq Markus Trippelsdorf
2017-03-31 13:27 ` Paolo Valente
2017-03-07 0:22 ` Bart Van Assche
2017-03-14 14:12 ` Paolo Valente
2017-03-07 1:00 ` Bart Van Assche
2017-03-14 15:35 ` Paolo Valente
2017-03-14 15:42 ` Jens Axboe
2017-03-14 16:32 ` Bart Van Assche
2017-03-18 10:52 ` Paolo Valente
2017-03-18 17:09 ` Linus Walleij
2017-03-18 17:46 ` Bart Van Assche
2017-03-18 20:46 ` Linus Walleij
2017-03-19 12:14 ` Paolo Valente
2017-03-20 18:40 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d37a7169-f279-8244-19f8-440dc1490893@kernel.dk \
--to=axboe@kernel.dk \
--cc=avanzini.arianna@gmail.com \
--cc=broonie@kernel.org \
--cc=fchecconi@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mauro.andreolini@unimore.it \
--cc=paolo.valente@linaro.org \
--cc=tj@kernel.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®