Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <0b4a9ba5-ed0d-e1a5-4982-8bad3e93f9b3@rasmusvillemoes.dk>
Date:   Fri, 17 Jun 2022 10:59:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: [PATCH v3 03/33] vsprintf: Convert to printbuf
Content-Language: en-US
To:     Kent Overstreet <kent.overstreet@gmail.com>,
        linux-kernel@vger.kernel.org
Cc:     pmladek@suse.com, rostedt@goodmis.org
References: <20220604193042.1674951-1-kent.overstreet@gmail.com>
 <20220604193042.1674951-4-kent.overstreet@gmail.com>
 <bc5daffb-e144-2a43-4657-eaf663e94750@rasmusvillemoes.dk>
 <ba8d21b8-7aae-6bfb-3553-3baba2bbeee1@gmail.com>
From:   Rasmus Villemoes <linux@rasmusvillemoes.dk>
In-Reply-To: <ba8d21b8-7aae-6bfb-3553-3baba2bbeee1@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 15/06/2022 20.44, Kent Overstreet wrote:
> On 6/15/22 05:09, Rasmus Villemoes wrote:

>> Anyway, my main concern with this is that performance goes down the
>> drain and the generated code will be awful. Have you done any
>> measurements and/or looked at disassembly? Thanks to
>> -fno-strict-aliasing (or perhaps just because we're writing through a
>> char* pointer which IIRC may alias anything), I think the compiler will
>> be forced to reload prt->pos and prt->size over and over and over. I may
>> be wrong, of course, that happens often. Perhaps __restrict could
>> help, IDK.
> 
> If we care that much about sprintf performance we must have some
> benchmarks somewhere - could you point me at them?

Try 'perf top'. Or copy the meat of vsprintf.c (all the %p gunk can be
elided) and do some measurements in userspace, that's what I did when I
improved the decimal conversion a few years back.

And yes, "we" care about sprintf performance because it's used to
generate all those files in /proc, /sys etc. etc. which many tools (e.g.
top/ps) rely on.

Rasmus