From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751827AbbCVRaJ (ORCPT <rfc822;w@1wt.eu>);
	Sun, 22 Mar 2015 13:30:09 -0400
Received: from mail-qc0-f180.google.com ([209.85.216.180]:36185 "EHLO
	mail-qc0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751705AbbCVRaF (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 22 Mar 2015 13:30:05 -0400
MIME-Version: 1.0
In-Reply-To: <CACVxJT9BD=EDuQCzyd9EhLtgg8QAjeYoYAa45E443QBNwhz6NQ@mail.gmail.com>
References: <5500b987.kerYYCYfIffruy3Z%akpm@linux-foundation.org>
 <CACVxJT_enpRNoBf3TizQ2U1Z77viP6sCy3CGTMnhpzpkjDpqcw@mail.gmail.com>
 <87y4n0xxn3.fsf@rasmusvillemoes.dk> <20150314092104.GA1674@p183.telecom.by>
 <CACVxJT-NmSsVn9a0aKSbz=ZKrcMa4f4kBoie_Y1r8da+1zS2Ag@mail.gmail.com>
 <20150317150406.f4ec837c6787dc8f3d1661f2@linux-foundation.org> <CACVxJT9BD=EDuQCzyd9EhLtgg8QAjeYoYAa45E443QBNwhz6NQ@mail.gmail.com>
From: Denys Vlasenko <vda.linux@googlemail.com>
Date: Sun, 22 Mar 2015 18:29:44 +0100
Message-ID: <CAK1hOcP-1LybQXb+-8bPATzNS3eb3A8mfrZrGsuiYRcMrMTUTA@mail.gmail.com>
Subject: Re: + lib-vsprintfc-even-faster-decimal-conversion.patch added to -mm tree
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Linux Kernel <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>, Tejun Heo <tj@kernel.org>,
        KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Mar 19, 2015 at 1:17 PM, Alexey Dobriyan <adobriyan@gmail.com> wrote:
> 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,

This is a good point wrt top/ps.

But.

We will never get rid of vsprintf in kernel printing numbers.
And inevitably there are scenarios where for one reason or another
someone would need to print LOTS AND LOTS of them.
It does make perfect sense to optimize that, even after
top/ps would start using a more efficient channel to get their data.