When the deadline scheduler is used with a zoned block device, writes
to a zone will be dispatched one a a time. This causes the warning
message:
deadline: forced dispatching is broken (nr_sorted=X), please report this
to be displayed when switching to another elevator with the legacy I/O
path wh
On Wed, Sep 26, 2018 at 04:23:16PM +0900, Damien Le Moal wrote:
> When the deadline scheduler is used with a zoned block device, writes
> to a zone will be dispatched one a a time. This causes the warning
at a time? ^
Otherwise,
Reviewed-by: Johannes Thumshirn
--
Johanne
When the deadline scheduler is used with a zoned block device, writes
to a zone will be dispatched one at a time. This causes the warning
message:
deadline: forced dispatching is broken (nr_sorted=X), please report this
to be displayed when switching to another elevator with the legacy I/O
path w
trace_block_unplug() takes true for explicit unplugs and false for
implicit unplugs. schedule() unplugs are implicit and should be
reported as timer unplugs. While correct in the legacy code, this has
been inverted in blk-mq since 4.11.
Cc: sta...@vger.kernel.org
Fixes: bd166ef183c2 ("blk-mq-sch
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
But one very minor nitpick below:
> #ifdef CONFIG_PM
> +static inline void blk_pm_request_resume(struct request_queue *q)
> +{
> + if (q->dev && (q->rpm_status == RPM_SUSPENDED ||
> +q->rpm_status == RPM_SUSPENDING))
I usually
Looks fine,
Reviewed-by: Christoph Hellwig
Looks fine,
Reviewed-by: Christoph Hellwig
> list_for_each_entry(rq, &q->queue_head, queuelist) {
> - if (blk_pm_allow_request(rq))
> - return rq;
> -
> - if (rq->rq_flags & RQF_SOFTBARRIER)
> - break;
> +#ifdef CONFIG_PM
> +
On Fri, Sep 21, 2018 at 01:31:22PM -0700, Bart Van Assche wrote:
> Now that the blk-mq core processes power management requests
> (marked with RQF_PREEMPT) in other states than RPM_ACTIVE, enable
> runtime power management for blk-mq.
Looks fine,
Reviewed-by: Christoph Hellwig
We also need to r
On 9/26/18 1:30 AM, Damien Le Moal wrote:
> When the deadline scheduler is used with a zoned block device, writes
> to a zone will be dispatched one at a time. This causes the warning
> message:
>
> deadline: forced dispatching is broken (nr_sorted=X), please report this
>
> to be displayed when
On Wed, Sep 26, 2018 at 04:27:40PM +0200, Christoph Hellwig wrote:
> > list_for_each_entry(rq, &q->queue_head, queuelist) {
> > - if (blk_pm_allow_request(rq))
> > - return rq;
> > -
> > - if (rq->rq_flags & RQF_SOFTBARRIER)
On Wed, Sep 26, 2018 at 04:43:57PM +0200, Johannes Thumshirn wrote:
> > assert, so I guess we'll have to live with it..
>
> How about:
> if (IS_ENABLED(CONFIG_PM))
> WARN_ON_ONCE(q->rpm_status == RPM_SUSPENDED);
I don't think this actually works give
On Wed, Sep 26, 2018 at 04:57:32PM +0200, Christoph Hellwig wrote:
> I don't think this actually works given that rpm_status only exists
> if CONFIG_PM is set.
I think it'll work as GCC does constant propagation. There are
actually some places in the kernel that follow this pattern.
Joha
On Wed, 2018-09-26 at 16:30 +0900, Damien Le Moal wrote:
> diff --git a/block/elevator.c b/block/elevator.c
> index 6a06b5d040e5..8cd81fd6339a 100644
> --- a/block/elevator.c
> +++ b/block/elevator.c
> @@ -609,7 +609,7 @@ void elv_drain_elevator(struct request_queue *q)
>
> while (e->type->
Lot of controllers may have only one irq vector for completing IO
request. And usually affinity of the only irq vector is all possible
CPUs, however, on most of ARCH, there may be only one specific CPU
for handling this interrupt.
So if all IOs are completed in hardirq context, it is inevitable to
Hello, Bart.
On Mon, Sep 24, 2018 at 01:43:35PM -0700, Bart Van Assche wrote:
> Thanks for the review. But could you please clarify what "after ->percpu_ref
> is called" refers to?
Oops, sorry, I meant the confirm_kill callback of
percpu_ref_kill_and_confirm().
Thanks.
--
tejun
On Wed, 2018-09-26 at 17:06 +0200, Johannes Thumshirn wrote:
> On Wed, Sep 26, 2018 at 04:57:32PM +0200, Christoph Hellwig wrote:
> > I don't think this actually works given that rpm_status only exists
> > if CONFIG_PM is set.
>
> I think it'll work as GCC does constant propagation. There are
> ac
On Wed, 2018-09-26 at 09:59 -0700, Tejun Heo wrote:
> Hello, Bart.
>
> On Mon, Sep 24, 2018 at 01:43:35PM -0700, Bart Van Assche wrote:
> > Thanks for the review. But could you please clarify what "after ->percpu_ref
> > is called" refers to?
>
> Oops, sorry, I meant the confirm_kill callback of
Instead of allowing requests that are not power management requests
to enter the queue in runtime suspended status (RPM_SUSPENDED), make
the blk_get_request() caller block. This change fixes a starvation
issue: it is now guaranteed that power management requests will be
executed no matter how many
The RQF_PREEMPT flag is used for three purposes:
- In the SCSI core, for making sure that power management requests
are executed even if a device is in the "quiesced" state.
- For domain validation by SCSI drivers that use the parallel port.
- In the IDE driver, for IDE preempt requests.
Rename "
Hello Jens,
One of the pieces that is missing before blk-mq can be made the default
is implementing runtime power management support for blk-mq. This patch
series not only implements runtime power management for blk-mq but also
fixes a starvation issue in the power management code for the legacy
Move the code for runtime power management from blk-core.c into the
new source file blk-pm.c. Move the corresponding declarations from
into . For CONFIG_PM=n, leave out
the declarations of the functions that are not used in that mode.
This patch not only reduces the number of #ifdefs in the block
A later patch will call blk_freeze_queue_start() followed by
blk_mq_unfreeze_queue() without waiting for q_usage_counter to drop
to zero. Make sure that this doesn't cause a kernel warning to appear
by switching from percpu_ref_reinit() to percpu_ref_resurrect(). The
former namely requires that the
Instead of scheduling runtime resume of a request queue after a
request has been queued, schedule asynchronous resume during request
allocation. The new pm_request_resume() calls occur after
blk_queue_enter() has increased the q_usage_counter request queue
member. This change is needed for a later
Now that the blk-mq core processes power management requests
(marked with RQF_PREEMPT) in other states than RPM_ACTIVE, enable
runtime power management for blk-mq.
Signed-off-by: Bart Van Assche
Reviewed-by: Ming Lei
Reviewed-by: Christoph Hellwig
Cc: Jianchao Wang
Cc: Hannes Reinecke
Cc: Joh
Move the pm_request_resume() and pm_runtime_mark_last_busy() calls into
two new functions and thereby separate legacy block layer code from code
that works for both the legacy block layer and blk-mq. A later patch will
add calls to the new functions in the blk-mq code.
Signed-off-by: Bart Van Assc
This function will be used in a later patch to switch the struct
request_queue q_usage_counter from killed back to live. In contrast
to percpu_ref_reinit(), this new function does not require that the
refcount is zero.
Signed-off-by: Bart Van Assche
Acked-by: Tejun Heo
Reviewed-by: Ming Lei
Cc:
On 9/26/18 3:01 PM, Bart Van Assche wrote:
> Hello Jens,
>
> One of the pieces that is missing before blk-mq can be made the default
> is implementing runtime power management support for blk-mq. This patch
> series not only implements runtime power management for blk-mq but also
> fixes a starva
Jens,
>> One of the pieces that is missing before blk-mq can be made the default
>> is implementing runtime power management support for blk-mq. This patch
>> series not only implements runtime power management for blk-mq but also
>> fixes a starvation issue in the power management code for the
On 9/26/18 3:14 PM, Martin K. Petersen wrote:
>
> Jens,
>
>>> One of the pieces that is missing before blk-mq can be made the default
>>> is implementing runtime power management support for blk-mq. This patch
>>> series not only implements runtime power management for blk-mq but also
>>> fixes
Hello
Please i still await your response regarding my previous email.
When the deadline scheduler is used with a zoned block device, writes
to a zone will be dispatched one at a time. This causes the warning
message:
deadline: forced dispatching is broken (nr_sorted=X), please report this
to be displayed when switching to another elevator with the legacy I/O
path w
On 9/26/18 7:55 PM, Damien Le Moal wrote:
> When the deadline scheduler is used with a zoned block device, writes
> to a zone will be dispatched one at a time. This causes the warning
> message:
>
> deadline: forced dispatching is broken (nr_sorted=X), please report this
>
> to be displayed when
Hi Ming,
On 09/27/2018 12:08 AM, Ming Lei wrote:
> Lot of controllers may have only one irq vector for completing IO
> request. And usually affinity of the only irq vector is all possible
> CPUs, however, on most of ARCH, there may be only one specific CPU
> for handling this interrupt.
Does this
Hi Dongli,
On Thu, Sep 27, 2018 at 10:00:28AM +0800, Dongli Zhang wrote:
> Hi Ming,
>
> On 09/27/2018 12:08 AM, Ming Lei wrote:
> > Lot of controllers may have only one irq vector for completing IO
> > request. And usually affinity of the only irq vector is all possible
> > CPUs, however, on most
Hi Ming
On 09/27/2018 12:08 AM, Ming Lei wrote:
> Lot of controllers may have only one irq vector for completing IO
> request. And usually affinity of the only irq vector is all possible
> CPUs, however, on most of ARCH, there may be only one specific CPU
> for handling this interrupt.
>
> So if
On Wed, Sep 26, 2018 at 11:24:55AM -0700, Bart Van Assche wrote:
> On Wed, 2018-09-26 at 17:06 +0200, Johannes Thumshirn wrote:
> > On Wed, Sep 26, 2018 at 04:57:32PM +0200, Christoph Hellwig wrote:
> > > I don't think this actually works given that rpm_status only exists
> > > if CONFIG_PM is set.
38 matches
Mail list logo
