From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fs/proc/array.c: slightly improve render_sigset_t
Date: Wed, 21 Sep 2016 22:51:12 +0200 [thread overview]
Message-ID: <87twd9c6yn.fsf@rasmusvillemoes.dk> (raw)
In-Reply-To: <CAGXu5jJTWnHh6EV9Vo6E7BRcHBaEGpHZkUtAZo+Eix6xL4PKEQ@mail.gmail.com> (Kees Cook's message of "Tue, 20 Sep 2016 17:16:09 -0700")
On Wed, Sep 21 2016, Kees Cook <keescook@chromium.org> wrote:
> On Tue, Sep 20, 2016 at 3:28 PM, Rasmus Villemoes
> <linux@rasmusvillemoes.dk> wrote:
>> format_decode and vsnprintf occasionally show up in perf top, so I
>> went looking for places that might not need the full printf
>> power. With the help of kprobes, I gathered some statistics on which
>> format strings we mostly pass to vsnprintf. On a trivial desktop
>> workload, I hit "%x" 25% of the time, so something apparently reads
>> /proc/pid/status (which does 5*16 printf("%x") calls) a lot.
>>
>> With this patch, reading /proc/pid/status is 30% faster according to
>> this microbenchmark:
>>
>> char buf[4096];
>> int i, fd;
>> for (i = 0; i < 10000; ++i) {
>> fd = open("/proc/self/status", O_RDONLY);
>> read(fd, buf, sizeof(buf));
>> close(fd);
>> }
>>
>> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>
> Heheh. Nice. :)
>
> Acked-by: Kees Cook <keescook@chromium.org>
>
> Out of curiosity, what other stuff ended up near the top? I'd be
> curious to see your kprobes too.
I don't have the results from the other machine handy, but it very much
depends on what one is doing. I ran a 'find $HOME ...', and "%.2x" ended
up accounting for 99%. Turns out ecryptfs does a lot of bin-to-hex
conversions, but very inefficiently (calling sprintf("%.2x") in a
loop...). Patch sent.
Other than that, the top consists of stuff like
"%c%c " (/proc/pid/smaps, VmFlags:)
" %s" (/proc/cpuinfo, the flags: line)
"%*s" (maybe from seq_pad, but not sure who the user of that is)
and a lot of other short strings which are rather hard to trace to their
source, but presumably most are related to some /proc file.
The kprobe is just
echo 'p:vsnprintf vsnprintf fmt=+0(%dx):string' > /sys/kernel/debug/tracing/kprobe_events
This doesn't escape the strings, so embedded newlines mess up the trace
buffer slightly. I used this little piece of line noise to extract the
format strings.
use File::Slurp;
my $txt = read_file($ARGV[0]);
while ($txt =~ m/fmt="(.*?)"\n/mg) {
$_ = $1;
s/\\/\\\\/g; s/\n/\\n/g;
s/\t/\\t/g; s/"/\\"/g;
print "\"$_\"\n";
}
Rasmus
next prev parent reply other threads:[~2016-09-21 20:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-20 22:28 [PATCH] fs/proc/array.c: slightly improve render_sigset_t Rasmus Villemoes
2016-09-21 0:16 ` Kees Cook
2016-09-21 20:51 ` Rasmus Villemoes [this message]
2016-10-05 22:48 ` Rasmus Villemoes
2016-10-06 22:35 ` Andrew Morton
2016-11-09 21:40 ` Andrei Vagin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87twd9c6yn.fsf@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes.dk \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox