Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC PATCH 00/13] x86 User Interrupts support
To:     Stefan Hajnoczi <stefanha@redhat.com>,
        Andy Lutomirski <luto@kernel.org>
CC:     the arch/x86 maintainers <x86@kernel.org>,
        Tony Luck <tony.luck@intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>, Jens Axboe <axboe@kernel.dk>,
        Christian Brauner <christian@brauner.io>,
        "Peter Zijlstra (Intel)" <peterz@infradead.org>,
        Shuah Khan <shuah@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
        Jonathan Corbet <corbet@lwn.net>,
        Raj Ashok <ashok.raj@intel.com>,
        Jacob Pan <jacob.jun.pan@linux.intel.com>,
        "Gayatri Kammela" <gayatri.kammela@intel.com>,
        Zeng Guang <guang.zeng@intel.com>,
        "Williams, Dan J" <dan.j.williams@intel.com>,
        Randy E Witt <randy.e.witt@intel.com>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        Ramesh Thomas <ramesh.thomas@intel.com>,
        Linux API <linux-api@vger.kernel.org>,
        <linux-arch@vger.kernel.org>,
        "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
        <linux-kselftest@vger.kernel.org>
References: <20210913200132.3396598-1-sohil.mehta@intel.com>
 <456bf9cf-87b8-4c3d-ac0c-7e392bcf26de@www.fastmail.com>
 <YVXmGTo5Uzp44QQq@stefanha-x1.localdomain>
From:   Sohil Mehta <sohil.mehta@intel.com>
Message-ID: <778d40fe-ad8e-fd7c-4caa-499910bb0925@intel.com>
Date:   Thu, 30 Sep 2021 10:24:24 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Firefox/78.0 Thunderbird/78.14.0
In-Reply-To: <YVXmGTo5Uzp44QQq@stefanha-x1.localdomain>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?Windows-1252?Q?05sjFsorYqWsOi6Uj/FHM1Vk54DbJ+W6Ikdws7T7TXFOUsnJHRLPD6oU?=
 =?Windows-1252?Q?oKPIXPdEdKyemuHvaTe9FgVcOmawnhm3OkauvjkgFP/s26CrI9ZMq7Hd?=
 =?Windows-1252?Q?uAtytEo/j4eU3GKSaGRjYa6HMInj3Wu7YO/2JHl/T9Nuv7ULA1vGKQmV?=
 =?Windows-1252?Q?Xejrlwmz/jyDri3ZLvrfPKabywBua66Esp2jHE2ooeJgNF3i2jR8puC7?=
 =?Windows-1252?Q?iFPjFRKoJlMLkturIrDQAXMOT8c/1wxZCpt5F5WQ/Szm/UNNrj7628tg?=
 =?Windows-1252?Q?/IltCQvDyTZIM7j+qrX0mFJGwEykcdhOdUmUHmO1jHkeUxnoK/oJvKny?=
 =?Windows-1252?Q?I14ii7BupU2WKjqLP4tyg2wBTNAIaSL94FGjiedjr0p2XNBszYC+Fe8M?=
 =?Windows-1252?Q?c/QaRcNh/jSdTuOok3BpYORdbiYpPMJr27qpdzDJbwO+Rz2e+NQOlPPI?=
 =?Windows-1252?Q?9QMoK/tnVTrHIpYJt1tA0Jzicjm86QrgHgEHmRiuesrvnek3t2FW2wwa?=
 =?Windows-1252?Q?HQKFwfo+QKRj5CsSz9SHso5fUhJAHA1ivoVaWl8k1+yeN3XhgUkA2i6O?=
 =?Windows-1252?Q?bapoDIEOL3UUkbWiUJ1tYAF17sKHaa5LrB1+lPYyXfPiu/PDeqnqd9tG?=
 =?Windows-1252?Q?FCSJAmklORddk9FkDB9W6R/Rt9k2Nc3FYFzEA90A9PH5B+D0JTxsBNJY?=
 =?Windows-1252?Q?odVU76WeqDoDd1SGUtetD9Kk5lZQ4hT8QYL5gT0bwtV46+/MhMosX2mf?=
 =?Windows-1252?Q?XduQZQasKixBwglMD085kWg/cE09SsoEeX9O+EizC9fcsPaLuB36sTWi?=
 =?Windows-1252?Q?oN018MHpFBaOU0Jp76fgjUQDVwmrj6nnWkBxy8/2CK8/HNc1RwkfQhA+?=
 =?Windows-1252?Q?6uYk4QAAeb/ijEwV7zGyz0/Eyt8F1KzR3xolzd4nqwLjOl4ubKytmajA?=
 =?Windows-1252?Q?VGb9DHxkhbjKdJGDNXrN7mRvHJldLk0eUdyyNJp7GxYYrWYi1Ke1YtjA?=
 =?Windows-1252?Q?C9rJAJankkdMr85OoMBqC0nFzJ+BkgYvGr9abQH5CHy/57amAIFjyIWY?=
 =?Windows-1252?Q?nQSzZNTF9Hy7MFAEzEyu9Hq07LeWUek9RdlDq/TycqIQzi3G3K8dMZSU?=
 =?Windows-1252?Q?GUR55pKmtAlQ0gISbu8KoNaJLyRj81SID8+OtE1J2KxqbjQlzDur44JH?=
 =?Windows-1252?Q?42HnwNwzO/OEH8v9p44y2WN1vRwnH6GHLMUrCI48XfbbhL+eeYZBz+sR?=
 =?Windows-1252?Q?EhOuQ3jP1+Kbqyr03VAbSKjOU1kDHuLghJLz4izogz0Ry5V5pPvbngEc?=
 =?Windows-1252?Q?DjWyPMFxw73NAs+K70STE5furKMr0Rpu6hSTwZbqax0Cay9nTfTAFmwg?=
 =?Windows-1252?Q?wSwTrqaxCuOK/vY8xNFFX7mZGJyFrJLwEYvm/lQDEMTaU+6XnMfgrkyT?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 2fe542f7-17d9-462d-8b64-08d98437274d
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3320.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2021 17:24:27.0435
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: cJdZjmwDlWDkSrUrBhDjnkwdSVIy6Qxvt4D/8mAbc0KscD3i0XFPMtb7zi1ZZbtw4CQOeK54Da/jVBjGTtsNqw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5022
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


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.


> (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?


Thanks,
Sohil