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 1E503C4332F for ; Thu, 30 Sep 2021 17:27:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 04F6E613A0 for ; Thu, 30 Sep 2021 17:27:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352668AbhI3R3F (ORCPT ); Thu, 30 Sep 2021 13:29:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:40900 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352606AbhI3R3E (ORCPT ); Thu, 30 Sep 2021 13:29:04 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 595EB6137A; Thu, 30 Sep 2021 17:27:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1633022841; bh=/0C11BR2NcWcrknqe3Jef9DMxhZDB9pEs6MHYZPMVss=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=JY3R+b3M4LV4FvPcQQ9Wn7grCq2Z36+1IxMR8ecV+Y7EQTZLwP0xcj+F0R6a/702z pNRt+ec6zFQkS36emeXZS4SF+8ZC/7r+qf5ExF6j3xALFDfDRpwsePsiK/FO92qrtP b8KJKarrsxoIPxh5S3GlhnsrAkrFrQkwy3DJH23vClkLI+Dp7Zr2fSuIhJOF3NoXJU s+agUlcSuV6mYAdTnahSi8DUh47FKXIsnBOPPDp+GdwpWQpM32CiRjNCg5gLqZ/JEy XTl4SSiSJC3ajOaruB+72dNH/uH5GafOdbw4aRsfkKT99lNsI6WFC/VRmh6G5txK67 sxRlGi7uycXGQ== Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 67C2827C007B; Thu, 30 Sep 2021 13:27:18 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute6.internal (MEProxy); Thu, 30 Sep 2021 13:27:18 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudekgedgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnheptdfhheettddvtedvtedugfeuuefhtddugedvleevleefvdetleff gfefvdekgeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudek heeifedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuh igrdhluhhtohdruhhs X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3CD8621E0063; Thu, 30 Sep 2021 13:27:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1322-g921842b88a-fm-20210929.001-g921842b8 Mime-Version: 1.0 Message-Id: In-Reply-To: <778d40fe-ad8e-fd7c-4caa-499910bb0925@intel.com> References: <20210913200132.3396598-1-sohil.mehta@intel.com> <456bf9cf-87b8-4c3d-ac0c-7e392bcf26de@www.fastmail.com> <778d40fe-ad8e-fd7c-4caa-499910bb0925@intel.com> Date: Thu, 30 Sep 2021 10:26:55 -0700 From: "Andy Lutomirski" To: "Sohil Mehta" , "Stefan Hajnoczi" Cc: "the arch/x86 maintainers" , "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 Thu, Sep 30, 2021, at 10:24 AM, Sohil Mehta wrote: > On 9/30/2021 9:30 AM, Stefan Hajnoczi wrote: >> On Tue, Sep 28, 2021 at 09:31:34PM -0700, Andy Lutomirski wrote: >>> >>> 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 was wondering the same thing. One thing came to mind: >> >> An application that wants to be *interrupted* from what it's doing >> rather than waiting until the next polling point. For example, >> applications that are CPU-intensive and have green threads. I can't name >> a real application like this though :P. > > Thank you Stefan and Andy for giving this some thought. > > We are consolidating the information internally on where and how exactly > we expect to see benefits with real workloads for the various sources of > User Interrupts. It will take a few days to get back on this one. Thanks! > > >> (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, can you please provide some more context/details on this? Is this > regarding the blocking syscalls discussion (in patch 11) or something else? > Yes, and I'll follow up there. I hereby upgrade my opinion of SENDUIPI wakeups to "probably doable but maybe not in a nice way."