lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 23 Sep 2021 16:09:07 -0700 From: Sohil Mehta <sohil.mehta@...el.com> To: Greg KH <gregkh@...uxfoundation.org> CC: "Hansen, Dave" <dave.hansen@...el.com>, "x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Luck, Tony" <tony.luck@...el.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, "H . Peter Anvin" <hpa@...or.com>, "Lutomirski, Andy" <luto@...nel.org>, Jens Axboe <axboe@...nel.dk>, Christian Brauner <christian@...uner.io>, Peter Zijlstra <peterz@...radead.org>, Shuah Khan <shuah@...nel.org>, Arnd Bergmann <arnd@...db.de>, Jonathan Corbet <corbet@....net>, "Raj, Ashok" <ashok.raj@...el.com>, Jacob Pan <jacob.jun.pan@...ux.intel.com>, "Kammela, Gayatri" <gayatri.kammela@...el.com>, "Zeng, Guang" <guang.zeng@...el.com>, "Williams, Dan J" <dan.j.williams@...el.com>, "Witt, Randy E" <randy.e.witt@...el.com>, "Shankar, Ravi V" <ravi.v.shankar@...el.com>, "Thomas, Ramesh" <ramesh.thomas@...el.com>, "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>, "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>, "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org> Subject: Re: [RFC PATCH 00/13] x86 User Interrupts support On 9/23/2021 5:19 AM, Greg KH wrote: > On Tue, Sep 14, 2021 at 07:03:36PM +0000, Mehta, Sohil wrote: > > 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? Thanks Greg for reviewing the patches. The reason I have not included absolute numbers is that on a pre-production platform it could be misleading. The data here is more of an approximation with the final performance expected to trend in this direction. I have used the term "relative" only to signify that this is comparing User IPI with others. Let's say, if eventfd took 9.7 usec on a system then User IPI (running) would take 1 usec. So it would still be a 9x improvement. But, I agree with your point. This is only a micro-benchmark performance comparison. The overall gain in a real workload would depend on how it uses IPC. +---------------------+------------------------------+ | IPC type | Example Latency | | | (micro seconds) | +---------------------+------------------------------+ | User IPI (running) | 1.0 usec | | User IPI (blocked) | 8.9 usec | | Signal | 14.8 usec | | Eventfd | 9.7 usec | | Pipe | 16.3 usec | | Domain | 17.3 usec | +---------------------+------------------------------+ > And this is really only for the "one userspace task waking up another > userspace task" policies. What real workload can actually use this? A User IPI sender could be registered to send IPIs to multiple targets. But, there is no broadcast mechanism, so it can only target one receiver everytime it executes the SENDUIPI instruction. Thanks, Sohil > thanks, > > greg k-h
Powered by blists - more mailing lists