Received: by 10.223.176.46 with SMTP id f43csp632656wra; Fri, 26 Jan 2018 04:32:33 -0800 (PST) X-Google-Smtp-Source: AH8x224fxnYm6/Kp7ZtvdjcnHfdnFYu+OE6vsd9aIn69DvP8qifZq3gMNoQMGe5d4Ujaz6UR+f8p X-Received: by 2002:a17:902:8608:: with SMTP id f8-v6mr14550354plo.366.1516969953091; Fri, 26 Jan 2018 04:32:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516969953; cv=none; d=google.com; s=arc-20160816; b=uKBKS1vs+5KTIsqzwE6kYNT0gXj620/p7FSCAb5miUOVf3c97kYQNC72EVyYEQzbvV n276wjje75VSvgYwzDoEoetkwZLJdlbaFs8zazwKLJ8pSVKyJUDoQRL+6Dj8yfC1nMXO i+gUBYMnSzuIsuHOnC81ZIg0kOykKc532o0YN1ZbDEFcv++AL6APQ9SOZnjuI9IeXouL QyFq6jmmHi1Ddfll1n3IrQuV+vMWOgvYLo+3hFODf1t3sG05/n492C4+BUAYb9iP5umE SzyRHbTF/MqLLjWa0787zH9ag0hDbwAVhxYYqDH78HRYSzB5XS+pAo50aFUM79r8aj1g t31g== 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:arc-authentication-results; bh=YGSNmWmUvv8EBJkLOkQEK9aWQzWDmHKqw5IKC0Is6KI=; b=WDnrh6qMC/k5HcH9kXcEWWfbyEF+UzFhsZNwyeaIG9FoLopysqMlVFvLbmjGi+KOKG 41DIUfd7kkrM3k3nRshRocALMTQBPKoPMfLtHWMqe0CEPib8/nA4RkL9exdInv/wxI66 jmAb+RkOpwrvumWYTzoqBViIXkarGBuGlyK6g6VqAk+8Qlmm0sZYWMWFsjf+A3nmixvI Vjc00vn5X6qkhC+GkqbJLxHltHUqzPs0UJCxZgBD/EYUPwT/BneYPJzHx6RfiQGopxBj xnMeGPy2G1tRzn1Wn1YSqRIQ5OMkGUNpt0ea1piKTbz+R4L8yzKYeKkxe8GkexqsH/Fp 3Zrw== ARC-Authentication-Results: i=1; mx.google.com; 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 a18si6289193pfg.271.2018.01.26.04.32.18; Fri, 26 Jan 2018 04:32:33 -0800 (PST) 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; 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 S1752024AbeAZMbb (ORCPT + 99 others); Fri, 26 Jan 2018 07:31:31 -0500 Received: from verein.lst.de ([213.95.11.211]:42605 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751868AbeAZMb0 (ORCPT ); Fri, 26 Jan 2018 07:31:26 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 169FB68C35; Fri, 26 Jan 2018 13:31:24 +0100 (CET) Date: Fri, 26 Jan 2018 13:31:23 +0100 From: Christoph Hellwig To: Benjamin LaHaise Cc: Christoph Hellwig , viro@zeniv.linux.org.uk, Avi Kivity , linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: aio poll, io_pgetevents and a new in-kernel poll API V4 Message-ID: <20180126123123.GA6985@lst.de> References: <20180122201243.31610-1-hch@lst.de> <20180125201025.GN23664@kvack.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180125201025.GN23664@kvack.org> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 25, 2018 at 03:10:25PM -0500, Benjamin LaHaise wrote: > I implemented something similar back in December, but did so without > changing the in-kernel poll API. See below for the patch that implements > it. Is changing the in-kernel poll API really desirable given how many > drivers that will touch? I had various previous versions that did not touch the driver API, but there are a couple issues with that: (1) you cannot make the API race free. With the existing convoluted poll_table_struct-based API you can't check for pending items before adding yourself to the waitqueue in a race free manner. (2) you cannot make the submit non-blocking without deferring to a workqueue or similar and thus incurring another context switch (3) you cannot deliver events from the wakeup callback, incurring another context switch, this time in the wakeup path that actually matters for some applications (3) the in-kernel poll API really is broken to start with and needs to be fixed anyway. I'd rather rely on that instead of working around decades old cruft that has no reason to exist.