Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1415671ybn; Wed, 25 Sep 2019 18:05:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqyoLi2wpmgiJOwb3UWUOw2QNw5fMIfLLN0gay9kIpktwZzpZtD8E0C/iXiPPP745wcDzRp3 X-Received: by 2002:a05:6402:2022:: with SMTP id ay2mr905799edb.109.1569459923555; Wed, 25 Sep 2019 18:05:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569459923; cv=none; d=google.com; s=arc-20160816; b=asE5xwm96VL5WHFtpokd9fdRUjVUuJGvUsreKfbAxoEazk0yeaywFM7Wxz8alh6FJf qF7vOEvgI00w6XZtkhfv/WpeD1ooihGhshEqTDXHgxgE2DnkEESsu2tMU8AcBA+VmiUg cinfe4L5gFCiYBbLqwZMyOH2siD2l7mDzInJMBUR9VVsI89h9xXMQaBQAmkBS89AcpzH YnJfS+hhCIs/Ili+M/iVBRCZ2FhM1rjE7czfcnm0rCtfvhcfnyv3ccBGhP4CQoG+Djqd aiy+oH31ZiWu/6aofxOVa/XXMuUNNX7IAIyv0ezhWSHVjX48JDaxoes5yTiLeVwsT/aB jKZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=J0LZ/gusRdLyBWuYJRWJKvWsgZDGpCWr1sFbbmR0ywU=; b=ohUax5Dl9JCqSoK38I8f21JuKts+SWS5Wuhm4NFgsFZ/kDIwIAxWSzWiT5uz7nI1Ne aDUQssierwcWYXwJbY6+YEHWsXG2yGvNnL5afe6rFxGIs3mAo0hqPTMLji3fcYsPY/9/ JumFh+go/zDOf3FbiCUYQq+aFYnoJHiwc5uAJt8yiwltSDImNjkwFbq01Ux8TBGISqkl UGOs6YOB9JJ/wtGdCZOCt3olifDDTPJohWaFey4tvoKfZtHKTMsZv79/0JX2lMIfN0pT tndkMGnK5dNjj2YZdPO/sBWuligwPxTjRY/pix3b4LQrJzgwyippkL5i2+VqRtetxl1p 8BhA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=OrfOVB6y; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f57si415755edb.165.2019.09.25.18.04.58; Wed, 25 Sep 2019 18:05:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=OrfOVB6y; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2504398AbfIXJt5 (ORCPT + 99 others); Tue, 24 Sep 2019 05:49:57 -0400 Received: from merlin.infradead.org ([205.233.59.134]:47898 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392592AbfIXJt5 (ORCPT ); Tue, 24 Sep 2019 05:49:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=J0LZ/gusRdLyBWuYJRWJKvWsgZDGpCWr1sFbbmR0ywU=; b=OrfOVB6yh0tLqWmKmibVsYj7v Y7RqOoFoTFHmJzVEEnPzO3ycgqqjdiULaBY9g+B7fX5Tkv8bfG7OQc1yKMu/ppfwwywcBvNDxFeqM CpKae2SqC0H1jvs3m+ksS2xVys3D0Fhw12J3dN3Xf+iSRxKj+CeM6bBN5JNvFqXACz8WNwD0/skmY cz6O0kTvdGDsNORYDXbdaUIpGceNjwB9YHSL1utX6Le1a1NSncpcwXdAy5NNj5sAFeqPDZJRdqM4B oDelUPuFe3MkrthRQh5mef1PIn0q4B6QKufhPSu3KqqtDBE1sD3SCa0ta5ZeG2x5+IzGn4A6LtZgs i6q0ehSuw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.2 #3 (Red Hat Linux)) id 1iChS7-0006sx-Aj; Tue, 24 Sep 2019 09:49:47 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 76DDD305E35; Tue, 24 Sep 2019 11:48:57 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 054BF20D80D41; Tue, 24 Sep 2019 11:49:43 +0200 (CEST) Date: Tue, 24 Sep 2019 11:49:42 +0200 From: Peter Zijlstra To: Jens Axboe Cc: Pavel Begunkov , Ingo Molnar , Ingo Molnar , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/2] Optimise io_uring completion waiting Message-ID: <20190924094942.GN2349@hirez.programming.kicks-ass.net> References: <20190923083549.GA42487@gmail.com> <731b2087-7786-5374-68ff-8cba42f0cd68@kernel.dk> <759b9b48-1de3-1d43-3e39-9c530bfffaa0@kernel.dk> <43244626-9cfd-0c0b-e7a1-878363712ef3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 24, 2019 at 10:36:28AM +0200, Jens Axboe wrote: > +struct io_wait_queue { > + struct wait_queue_entry wq; > + struct io_ring_ctx *ctx; > + struct task_struct *task; wq.private is where the normal waitqueue stores the task pointer. (I'm going to rename that) > + unsigned to_wait; > + unsigned nr_timeouts; > +}; > + > +static inline bool io_should_wake(struct io_wait_queue *iowq) > +{ > + struct io_ring_ctx *ctx = iowq->ctx; > + > + /* > + * Wake up if we have enough events, or if a timeout occured since we > + * started waiting. For timeouts, we always want to return to userspace, > + * regardless of event count. > + */ > + return io_cqring_events(ctx->rings) >= iowq->to_wait || > + atomic_read(&ctx->cq_timeouts) != iowq->nr_timeouts; > +} > + > +static int io_wake_function(struct wait_queue_entry *curr, unsigned int mode, > + int wake_flags, void *key) > +{ > + struct io_wait_queue *iowq = container_of(curr, struct io_wait_queue, > + wq); > + > + if (io_should_wake(iowq)) { > + list_del_init(&curr->entry); > + wake_up_process(iowq->task); Then you can use autoremove_wake_function() here. > + return 1; > + } > + > + return -1; > +} Ideally we'd get wait_event()'s @cond in a custom wake function. Then we can _always_ do this. This is one I'd love to have lambda functions for. It would actually work with GCC nested functions, because the wake function will always be in scope, but we can't use those in the kernel for other reasons :/