Thread (40 messages) 40 messages, 6 authors, 2022-01-20

Re: [RFC][PATCH 3/3] sched: User Mode Concurency Groups

From: Peter Zijlstra <peterz@infradead.org>
Date: 2022-01-17 12:13:59
Also in: linux-mm, lkml

On Fri, Jan 14, 2022 at 03:09:55PM +0100, Peter Zijlstra wrote:
On Tue, Dec 21, 2021 at 05:19:00PM +0000, Peter Oskolkov wrote:
quoted
quoted
+	/*
+	 * Workers will still block in umcg_notify_resume() before they can
+	 * consume their error, servers however need to get the error asap.
+	 *
+	 * Still, things might be unrecoverably screwy after this. Not our
+	 * problem.
I think we should explicitly document the unrecoverable screwiness
of errors here, so that the userspace proactively kills itself
to avoid badness. The only reason that returning an error here is
mildly preferable to just killing the task (we already do that
in other places) is to give the userspace an opportunity to
log an error, with more state/info than we can do here.
Bah, I should've written a better comment, because I can't quite
remember the case I had in mind. Also, again from the LAZY patch, I
think we can actually do better in some of the cases here.

Specifically, currently we'll enqueue on ::runnable_workers_ptr and fail
waking ::next_tid and leave it at that. While I think waking
::server_tid in that case makes sense.

I'll go prod at this.
Is anybody actually planning to use ::next_tid for workers?

My current thinking is that much of the problems here stem from that.

Let me ponder more..
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help