[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAOGi=dMcQR+ydbz5WSxy_7s2=vFYeuyd+N+AC5NJaSvvdLbxEw@mail.gmail.com>
Date: Mon, 11 Apr 2016 16:00:18 +0800
From: Ling Ma <ling.ma.program@...il.com>
To: Waiman Long <waiman.long@....com>
Cc: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Peter Zijlstra <peterz@...radead.org>, mingo@...hat.com,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
Ling <ling.ml@...baba-inc.com>
Subject: Re: [RFC PATCH] alispinlock: acceleration from lock integration on
multi-core platform
Is it acceptable for performance improvement or more comments on this patch?
Thanks
Ling
2016-04-05 11:44 GMT+08:00 Ling Ma <ling.ma.program@...il.com>:
> Hi Longman,
>
>> with some modest increase in performance. That can be hard to justify. Maybe
>> you should find other use cases that involve less changes, but still have
>> noticeable performance improvement. That will make it easier to be accepted.
>
> The attachment is for other use case with the new lock optimization.
> It include two files: main.c (user space workload),
> fcntl-lock-opt.patch (kernel patch on 4.3.0-rc4 version)
> (The hardware platform is on Intel E5 2699 V3, 72 threads (18core *2Socket *2HT)
>
> 1. when we run a.out from main.c on original 4.3.0-rc4 version,
> the average throughput from a.out is 1887592( 98% cpu cost from perf top -d1)
>
> 2. when we run a.out from main.c with the fcntl-lock-opt.patch ,
> the average throughput from a.out is 5277281 (91% cpu cost from perf top -d1)
>
> So we say the new mechanism give us about 2.79x (5277281 / 1887592) improvement.
>
> Appreciate your comments.
>
> Thanks
> Ling
Powered by blists - more mailing lists