Messages in this thread | | | Date | Sat, 9 Jan 2016 06:44:15 +0800 | Subject | Re: [RFC PATCH] alispinlock: acceleration from lock integration on multi-core platform | From | Ling Ma <> |
| |
The attachment (alispinlock.tar.bz2) includes original spinlock and alispinlock , we compare them on 70 cores based on kernel 4.3, the alispinlock can improve performance upto 3x.
the link: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1035940.html indicates when we introduce the idea for real application(user space application caused the bottle neck from kernel spinlock ) the spinlock performance is improved by 1.9x (perf top -d1 also tell us the spinlock cost time is reduced from 25% to 15%).
Appreciate your comments Ling
2016-01-06 19:24 GMT+08:00 One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>: > On Wed, 6 Jan 2016 09:21:06 +0100 > Peter Zijlstra <peterz@infradead.org> wrote: > >> On Wed, Jan 06, 2016 at 09:16:43AM +0100, Peter Zijlstra wrote: >> > On Tue, Jan 05, 2016 at 09:42:27PM +0000, One Thousand Gnomes wrote: >> > > > It suffers the typical problems all those constructs do; namely it >> > > > wrecks accountability. >> > > >> > > That's "government thinking" ;-) - for most real users throughput is >> > > more important than accountability. With the right API it ought to also >> > > be compile time switchable. >> > >> > Its to do with having been involved with -rt. RT wants to do >> > accountability for such things because of PI and sorts. >> >> Also, real people really do care about latency too, very bad worst case >> spikes to upset things. > > Some yes - I'm familiar with the way some of the big financial number > crunching jobs need this. There are also people who instead care a lot > about throughput. Anything like this needs to end up with an external API > which looks the same whether the work is done via one thread or the other. > > Alan [unhandled content-type:application/x-bzip2] | |