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 X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82C33C4321E for ; Thu, 23 Sep 2021 14:09:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 63D4861019 for ; Thu, 23 Sep 2021 14:09:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241463AbhIWOLV (ORCPT ); Thu, 23 Sep 2021 10:11:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:35764 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241603AbhIWOLU (ORCPT ); Thu, 23 Sep 2021 10:11:20 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 22F9360F44; Thu, 23 Sep 2021 14:09:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1632406188; bh=ZTXZf30T3ZUc5R8VZRJeJBfdae5TPW0th0RClDFdmdM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RxK7Top7vHYOES/amPXJnFenVjo0z1GxYXGT3k/Pyxf3hwK+9RBPl2JQBMvA3rhgj ztdDDfIrLIkkNbZ4oLXX2AhB/qQ8rB/TQz4SMfzg5+od+heVr1b1aInMgefEGzDDjv xjSTc4pdVdE2p+fxWCl5UKcuHhuGEoZ0fIk4RucM= Date: Thu, 23 Sep 2021 16:09:46 +0200 From: Greg KH To: "Mehta, Sohil" Cc: "Hansen, Dave" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "Luck, Tony" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , "Lutomirski, Andy" , Jens Axboe , Christian Brauner , Peter Zijlstra , Shuah Khan , Arnd Bergmann , Jonathan Corbet , "Raj, Ashok" , Jacob Pan , "Kammela, Gayatri" , "Zeng, Guang" , "Williams, Dan J" , "Witt, Randy E" , "Shankar, Ravi V" , "Thomas, Ramesh" , "linux-api@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-kselftest@vger.kernel.org" Subject: Re: [RFC PATCH 00/13] x86 User Interrupts support Message-ID: References: <20210913200132.3396598-1-sohil.mehta@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Thu, Sep 23, 2021 at 02:19:05PM +0200, Greg KH wrote: > On Tue, Sep 14, 2021 at 07:03:36PM +0000, Mehta, Sohil wrote: > > Resending.. There were some email delivery issues. > > > > On 9/13/2021 1:27 PM, Dave Hansen wrote: > > > User Interrupts directly deliver events to user space and are > > > 10x faster than the closest alternative. > > > > Thanks Dave. This is definitely more attention-grabbing than the > > previous intro. I'll include this next time. > > > > One thing to note, the 10x gain is only applicable for User IPIs. > > For other source of User Interrupts (like kernel-to-user > > notifications and other external sources), we don't have the data > > yet. > > > > I realized the User IPI data in the cover also needs some > > clarification. The 10x gain is only seen when the receiver is > > spinning in User space - waiting for interrupts. > > > > If the receiver were to block (wait) in the kernel, the performance > > would drop as expected. However, User IPI (blocked) would still be > > 10% faster than Eventfd and 40% faster than signals. > > > > Here is the updated table: > > +---------------------+-------------------------+ > > | IPC type | Relative Latency | > > | |(normalized to User IPI) | > > +---------------------+-------------------------+ > > | User IPI | 1.0 | > > | User IPI (blocked) | 8.9 | > > | Signal | 14.8 | > > | Eventfd | 9.7 | > > | Pipe | 16.3 | > > | Domain | 17.3 | > > +---------------------+-------------------------+ > > Relative is just that, "relative". If the real values are extremely > tiny, then relative is just "this goes a tiny tiny bit faster than what > you have today in eventfd", right? > > So how about "absolute"? What are we talking here? > > And this is really only for the "one userspace task waking up another > userspace task" policies. What real workload can actually use this? Also, you forgot to list Binder in the above IPC type. And you forgot to mention that this is tied to one specific CPU type only. Are syscalls allowed to be created that would only work on obscure cpus like this one? thanks, greg k-h