Revision 6e2df0581f569038719cf2bc2b3baa3fcc83cab4 authored by Peter Zijlstra on 08 November 2019, 10:11:52 UTC, committed by Peter Zijlstra on 08 November 2019, 21:34:14 UTC
Commit 67692435c411 ("sched: Rework pick_next_task() slow-path")
inadvertly introduced a race because it changed a previously
unexplored dependency between dropping the rq->lock and
sched_class::put_prev_task().
The comments about dropping rq->lock, in for example
newidle_balance(), only mentions the task being current and ->on_cpu
being set. But when we look at the 'change' pattern (in for example
sched_setnuma()):
queued = task_on_rq_queued(p); /* p->on_rq == TASK_ON_RQ_QUEUED */
running = task_current(rq, p); /* rq->curr == p */
if (queued)
dequeue_task(...);
if (running)
put_prev_task(...);
/* change task properties */
if (queued)
enqueue_task(...);
if (running)
set_next_task(...);
It becomes obvious that if we do this after put_prev_task() has
already been called on @p, things go sideways. This is exactly what
the commit in question allows to happen when it does:
prev->sched_class->put_prev_task(rq, prev, rf);
if (!rq->nr_running)
newidle_balance(rq, rf);
The newidle_balance() call will drop rq->lock after we've called
put_prev_task() and that allows the above 'change' pattern to
interleave and mess up the state.
Furthermore, it turns out we lost the RT-pull when we put the last DL
task.
Fix both problems by extracting the balancing from put_prev_task() and
doing a multi-class balance() pass before put_prev_task().
Fixes: 67692435c411 ("sched: Rework pick_next_task() slow-path")
Reported-by: Quentin Perret <qperret@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Quentin Perret <qperret@google.com>
Tested-by: Valentin Schneider <valentin.schneider@arm.com>
1 parent e3b8b6a
ingenic-tcu.rst
.. SPDX-License-Identifier: GPL-2.0
===============================================
Ingenic JZ47xx SoCs Timer/Counter Unit hardware
===============================================
The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function
hardware block. It features up to to eight channels, that can be used as
counters, timers, or PWM.
- JZ4725B, JZ4750, JZ4755 only have six TCU channels. The other SoCs all
have eight channels.
- JZ4725B introduced a separate channel, called Operating System Timer
(OST). It is a 32-bit programmable timer. On JZ4760B and above, it is
64-bit.
- Each one of the TCU channels has its own clock, which can be reparented to three
different clocks (pclk, ext, rtc), gated, and reclocked, through their TCSR register.
- The watchdog and OST hardware blocks also feature a TCSR register with the same
format in their register space.
- The TCU registers used to gate/ungate can also gate/ungate the watchdog and
OST clocks.
- Each TCU channel works in one of two modes:
- mode TCU1: channels cannot work in sleep mode, but are easier to
operate.
- mode TCU2: channels can work in sleep mode, but the operation is a bit
more complicated than with TCU1 channels.
- The mode of each TCU channel depends on the SoC used:
- On the oldest SoCs (up to JZ4740), all of the eight channels operate in
TCU1 mode.
- On JZ4725B, channel 5 operates as TCU2, the others operate as TCU1.
- On newest SoCs (JZ4750 and above), channels 1-2 operate as TCU2, the
others operate as TCU1.
- Each channel can generate an interrupt. Some channels share an interrupt
line, some don't, and this changes between SoC versions:
- on older SoCs (JZ4740 and below), channel 0 and channel 1 have their
own interrupt line; channels 2-7 share the last interrupt line.
- On JZ4725B, channel 0 has its own interrupt; channels 1-5 share one
interrupt line; the OST uses the last interrupt line.
- on newer SoCs (JZ4750 and above), channel 5 has its own interrupt;
channels 0-4 and (if eight channels) 6-7 all share one interrupt line;
the OST uses the last interrupt line.
Implementation
==============
The functionalities of the TCU hardware are spread across multiple drivers:
=========== =====
clocks drivers/clk/ingenic/tcu.c
interrupts drivers/irqchip/irq-ingenic-tcu.c
timers drivers/clocksource/ingenic-timer.c
OST drivers/clocksource/ingenic-ost.c
PWM drivers/pwm/pwm-jz4740.c
watchdog drivers/watchdog/jz4740_wdt.c
=========== =====
Because various functionalities of the TCU that belong to different drivers
and frameworks can be controlled from the same registers, all of these
drivers access their registers through the same regmap.
For more information regarding the devicetree bindings of the TCU drivers,
have a look at Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
Computing file changes ...
