Thread (60 messages) 60 messages, 4 authors, 2019-01-31

Re: [PATCH 09/13] io_uring: add submission polling

flat view

From: Jens Axboe <axboe@kernel.dk>
Date: 2019-01-28 17:05:55
Also in: linux-fsdevel

On 1/28/19 8:09 AM, Christoph Hellwig wrote:
On Wed, Jan 23, 2019 at 08:35:22AM -0700, Jens Axboe wrote:
quoted
Proof of concept.
Is that still true?
I guess I can remove it now, dates back to when it was initially just
a test. But it should be solid, I'll kill that part.
quoted
1) Maybe have smarter backoff. Busy loop for X time, then go to
   monitor/mwait, finally the schedule we have now after an idle
   second. Might not be worth the complexity.

2) Probably want the application to pass in the appropriate grace
   period, not hard code it at 1 second.
2) actually sounds really useful.  Should we look into it ASAP?
I think so. Question is what kind of granularity we need for this. I
think we can go pretty coarse and keep it in msec, using a short to
pass this in like we do for the thread CPU. That gives us 0..65535 msec,
which should be plenty of range.
quoted
 	struct {
 		/* CQ ring */
@@ -264,6 +267,9 @@ static void __io_cqring_add_event(struct io_ring_ctx *ctx, u64 ki_user_data,
 
 	if (waitqueue_active(&ctx->wait))
 		wake_up(&ctx->wait);
+	if ((ctx->flags & IORING_SETUP_SQPOLL) &&
+	    waitqueue_active(&ctx->sqo_wait))
waitqueue_active is really cheap and sqo_wait should not otherwise
by active.  Do we really need the flags check here?
Probably not, I'll kill it.
quoted
+			/*
+			 * Normal IO, just pretend everything completed.
+			 * We don't have to poll completions for that.
+			 */
+			if (ctx->flags & IORING_SETUP_IOPOLL) {
+				/*
+				 * App should not use IORING_ENTER_GETEVENTS
+				 * with thread polling, but if it does, then
+				 * ensure we are mutually exclusive.
Should we just return an error early on in this case instead?
I think that'd make it awkward, since it's out-of-line. If the app is doing
things it shouldn't in this case, its own io_uring_enter() would most likely
fail occasionally with -EBUSY anyway.
quoted
 	if (to_submit) {
+		if (ctx->flags & IORING_SETUP_SQPOLL) {
+			wake_up(&ctx->sqo_wait);
+			ret = to_submit;
Do these semantics really make sense?  Maybe we should have an
IORING_ENTER_WAKE_SQ instead of overloading the to_submit argument?
Especially as we don't really care about returning the number passed in.
I like that change, I'll add IORING_ENTER_SQ_WAKEUP instead of using
'to_submit' for this. We can't validate the number anyway.
quoted
+	if (ctx->sqo_thread) {
+		kthread_park(ctx->sqo_thread);
Can you explain why we need the whole kthread_park game?  It is only
intended to deal with pausing a thread, and if need it to shut down
a thread we have a bug somewhere.
It is working around a bug in shutting down a thread that is affinitized
to a single CPU, I just didn't want to deal with hunting that down right
now.
quoted
 static void io_sq_offload_stop(struct io_ring_ctx *ctx)
 {
+	if (ctx->sqo_thread) {
+		kthread_park(ctx->sqo_thread);
+		kthread_stop(ctx->sqo_thread);
+		ctx->sqo_thread = NULL;
Also there isn't really much of a point in setting pointers to NULL
just before freeing the containing structure.  In the best case this
now papers over bugs that poisoning or kasan would otherwise find.
Removed.

-- 
Jens Axboe
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help