[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACVxJT9BD=EDuQCzyd9EhLtgg8QAjeYoYAa45E443QBNwhz6NQ@mail.gmail.com>
Date: Thu, 19 Mar 2015 15:17:10 +0300
From: Alexey Dobriyan <adobriyan@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Rasmus Villemoes <linux@...musvillemoes.dk>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Tejun Heo <tj@...nel.org>,
Denis Vlasenko <vda.linux@...glemail.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: + lib-vsprintfc-even-faster-decimal-conversion.patch added to -mm tree
On Wed, Mar 18, 2015 at 1:04 AM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
> On Mon, 16 Mar 2015 18:19:41 +0300 Alexey Dobriyan <adobriyan@...il.com> wrote:
>
>> Rasmus, I redid benchmarks:
>
> tl;dr ;) Is this an ack or a nack?
New code executes slower for some input on one CPU I've benchmarked,
both with -O2 and -Os (Core 2 Duo E6550). The slowdown is in 2-20% range
depending on exact number being converted and is reproducible.
With -O2 "bad" range is roughly 100-70000, with -Os it is 100-1000 and
around 100000.
On another CPU (more modern Core i5-something), new code is uniformly
faster giving advertised 10-20-35-40% speedups (yay!)
The ideal situation is still being
a) one system call to push PIDs into userspace in bulk
(memcpy directly from pid_ns->pidmap[i]),
b) one system call to fetch data in binary to userspace given PID or
set of PIDs,
without all of this string and /proc overhead.
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists