Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1487687 > unrolled thread

[PATCH] fs/proc/array.c: slightly improve render_sigset_t

Back to article view | Back to linux.kernel

Contents

  [PATCH] fs/proc/array.c: slightly improve render_sigset_t Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2016-09-21 00:30 +0200
    Re: [PATCH] fs/proc/array.c: slightly improve render_sigset_t Kees Cook <keescook@chromium.org> - 2016-09-21 02:20 +0200
      Re: [PATCH] fs/proc/array.c: slightly improve render_sigset_t Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2016-09-21 23:00 +0200

#1487687 — [PATCH] fs/proc/array.c: slightly improve render_sigset_t

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>
---
 fs/proc/array.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/proc/array.c b/fs/proc/array.c
index 88c7de12197b..7f73b689a15c 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -251,7 +251,7 @@ void render_sigset_t(struct seq_file *m, const char *header,
 		if (sigismember(set, i+2)) x |= 2;
 		if (sigismember(set, i+3)) x |= 4;
 		if (sigismember(set, i+4)) x |= 8;
-		seq_printf(m, "%x", x);
+		seq_putc(m, hex_asc[x]);
 	} while (i >= 4);
 
 	seq_putc(m, '\n');
-- 
2.1.4

[toc] | [next] | [standalone]

#1487733

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.

-Kees

> ---
>  fs/proc/array.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index 88c7de12197b..7f73b689a15c 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -251,7 +251,7 @@ void render_sigset_t(struct seq_file *m, const char *header,
>                 if (sigismember(set, i+2)) x |= 2;
>                 if (sigismember(set, i+3)) x |= 4;
>                 if (sigismember(set, i+4)) x |= 8;
> -               seq_printf(m, "%x", x);
> +               seq_putc(m, hex_asc[x]);
>         } while (i >= 4);
>
>         seq_putc(m, '\n');
> --
> 2.1.4
>



-- 
Kees Cook
Nexus Security

[toc] | [prev] | [next] | [standalone]

#1488387

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web