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..