From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CA6BC433F5 for ; Wed, 29 Sep 2021 04:32:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 344BA613A6 for ; Wed, 29 Sep 2021 04:32:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243938AbhI2Edu (ORCPT ); Wed, 29 Sep 2021 00:33:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:50754 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233412AbhI2Edo (ORCPT ); Wed, 29 Sep 2021 00:33:44 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3F3FC611BD; Wed, 29 Sep 2021 04:32:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1632889922; bh=0JwZBuC9ISIKWkfaCHpZoe2xKe6eZgUj8P+e9dRgmcA=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=EK+ZaX3RZ98lBZT/cEE3maXj+cA8JmNET5/gOuKZsMKKbXgo21lvmEuXLkapNfJ1F nCe+LZxlq7xsF7LCPUxhcSTjYuhTX0elDTzppiQ/BtSOV4ubsa2kSQNdb/vvi6gcS5 NEXm8GIF+c/VBbwEODTij153Ke8nIzKLXyLwwEpA8cISVqvPTyMRSqXx+eiVrxTFXN UxgFt4fZa91b4KbOgWiZkU2l6+gzvlSSLeZFvLotJMyd696M7IEkMFCaH2on21+nXb XsJo2rTuoDydcSJflndUnzajwyqp8jgEAU8BgOHjHYO8DZstSK11aWk1FBylToTu3U pbVpY+rhZ3Olw== Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 5C7E327C0054; Wed, 29 Sep 2021 00:31:59 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute6.internal (MEProxy); Wed, 29 Sep 2021 00:31:59 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudekuddgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdetnhgu hicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenucggtf frrghtthgvrhhnpedthfehtedtvdetvdetudfgueeuhfdtudegvdelveelfedvteelfffg fedvkeegfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegrnhguhidomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduiedukeeh ieefvddqvdeifeduieeitdekqdhluhhtoheppehkvghrnhgvlhdrohhrgheslhhinhhugi drlhhuthhordhush X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6378621E0063; Wed, 29 Sep 2021 00:31:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1303-gb2406efd75-fm-20210922.002-gb2406efd Mime-Version: 1.0 Message-Id: <456bf9cf-87b8-4c3d-ac0c-7e392bcf26de@www.fastmail.com> In-Reply-To: <20210913200132.3396598-1-sohil.mehta@intel.com> References: <20210913200132.3396598-1-sohil.mehta@intel.com> Date: Tue, 28 Sep 2021 21:31:34 -0700 From: "Andy Lutomirski" To: "Sohil Mehta" , "the arch/x86 maintainers" Cc: "Tony Luck" , "Dave Hansen" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "H. Peter Anvin" , "Jens Axboe" , "Christian Brauner" , "Peter Zijlstra (Intel)" , "Shuah Khan" , "Arnd Bergmann" , "Jonathan Corbet" , "Raj Ashok" , "Jacob Pan" , "Gayatri Kammela" , "Zeng Guang" , "Williams, Dan J" , "Randy E Witt" , "Shankar, Ravi V" , "Ramesh Thomas" , "Linux API" , linux-arch@vger.kernel.org, "Linux Kernel Mailing List" , linux-kselftest@vger.kernel.org Subject: Re: [RFC PATCH 00/13] x86 User Interrupts support Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 13, 2021, at 1:01 PM, Sohil Mehta wrote: > User Interrupts Introduction > ============================ > > User Interrupts (Uintr) is a hardware technology that enables delivering > interrupts directly to user space. > > Today, virtually all communication across privilege boundaries happens by going > through the kernel. These include signals, pipes, remote procedure calls and > hardware interrupt based notifications. User interrupts provide the foundation > for more efficient (low latency and low CPU utilization) versions of these > common operations by avoiding transitions through the kernel. > ... I spent some time reviewing the docs (ISE) and contemplating how this all fits together, and I have a high level question: Can someone give an example of a realistic workload that would benefit from SENDUIPI and precisely how it would use SENDUIPI? Or an example of a realistic workload that would benefit from hypothetical device-initiated user interrupts and how it would use them? I'm having trouble imagining something that wouldn't work as well or better by simply polling, at least on DMA-coherent architectures like x86. (I can imagine some benefit to a hypothetical improved SENDUIPI with idential user semantics but that supported a proper interaction with the scheduler and blocking syscalls. But that's not what's documented in the ISE...) --Andy