Thread (16 messages) 16 messages, 2 authors, 2018-08-22

Re: [PATCH 8/9] psi: pressure stall information for CPU, memory, and IO

From: Peter Zijlstra <peterz@infradead.org>
Date: 2018-08-22 09:16:52
Also in: linux-mm, lkml

Possibly related (same subject, not in this thread)

On Tue, Aug 21, 2018 at 03:44:13PM -0400, Johannes Weiner wrote:
quoted
quoted
+		for (s = PSI_NONIDLE; s >= 0; s--) {
+			u32 time, delta;
+
+			time = READ_ONCE(groupc->times[s]);
+			/*
+			 * In addition to already concluded states, we
+			 * also incorporate currently active states on
+			 * the CPU, since states may last for many
+			 * sampling periods.
+			 *
+			 * This way we keep our delta sampling buckets
+			 * small (u32) and our reported pressure close
+			 * to what's actually happening.
+			 */
+			if (test_state(groupc->tasks, cpu, s)) {
+				/*
+				 * We can race with a state change and
+				 * need to make sure the state_start
+				 * update is ordered against the
+				 * updates to the live state and the
+				 * time buckets (groupc->times).
+				 *
+				 * 1. If we observe task state that
+				 * needs to be recorded, make sure we
+				 * see state_start from when that
+				 * state went into effect or we'll
+				 * count time from the previous state.
+				 *
+				 * 2. If the time delta has already
+				 * been added to the bucket, make sure
+				 * we don't see it in state_start or
+				 * we'll count it twice.
+				 *
+				 * If the time delta is out of
+				 * state_start but not in the time
+				 * bucket yet, we'll miss it entirely
+				 * and handle it in the next period.
+				 */
+				smp_rmb();
+				time += cpu_clock(cpu) - groupc->state_start;
+			}
The alternative is adding an update to scheduler_tick(), that would
ensure you're never more than nr_cpu_ids * TICK_NSEC behind.
I wasn't able to convert *all* states to tick updates like this.

The reason is that, while testing rq->curr for PF_MEMSTALL is cheap,
other tasks associated with the rq could be from any cgroup in the
system. That means we'd have to do for_each_cgroup() on every tick to
keep the groupc->times that closely uptodate, and that wouldn't scale.
We tend to have hundreds of them, some setups have thousands.

Since we don't need to be *that* current, I left the on-demand update
inside the aggregator for now. It's a bit trickier, but much cheaper.
ARGH indeed; I was thinking we only need to update current. But because
we're tracking blocked state that doesn't work.

Sorry for that :/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help