Re: [PATCH] proc: faster /proc/*/status

2016-08-09 Thread Andrew Morton
On Sun, 07 Aug 2016 14:22:31 -0700 Joe Perches wrote: > On Sun, 2016-08-07 at 10:44 -0700, Andi Kleen wrote: > > > > > It is so bloated that gcc needs to be asked to not screw up with stack > > > > > size. > > > > What happens when you drop all the noinlines for this? I assume

Re: [PATCH] proc: faster /proc/*/status

2016-08-09 Thread Andrew Morton
On Sun, 07 Aug 2016 14:22:31 -0700 Joe Perches wrote: > On Sun, 2016-08-07 at 10:44 -0700, Andi Kleen wrote: > > > > > It is so bloated that gcc needs to be asked to not screw up with stack > > > > > size. > > > > What happens when you drop all the noinlines for this? I assume > > > > this would

Re: [PATCH] proc: faster /proc/*/status

2016-08-07 Thread Joe Perches
On Sun, 2016-08-07 at 10:44 -0700, Andi Kleen wrote: > > > > It is so bloated that gcc needs to be asked to not screw up with stack > > > > size. > > > What happens when you drop all the noinlines for this? I assume > > > this would alread make it faster. And now that we have bigger > > > stacks

Re: [PATCH] proc: faster /proc/*/status

2016-08-07 Thread Joe Perches
On Sun, 2016-08-07 at 10:44 -0700, Andi Kleen wrote: > > > > It is so bloated that gcc needs to be asked to not screw up with stack > > > > size. > > > What happens when you drop all the noinlines for this? I assume > > > this would alread make it faster. And now that we have bigger > > > stacks

Re: [PATCH] proc: faster /proc/*/status

2016-08-07 Thread Andi Kleen
> > > It is so bloated that gcc needs to be asked to not screw up with stack > > > size. > > What happens when you drop all the noinlines for this? I assume > > this would alread make it faster. And now that we have bigger > > stacks we can likely tolerate it. > > %pV recurses through these code

Re: [PATCH] proc: faster /proc/*/status

2016-08-07 Thread Andi Kleen
> > > It is so bloated that gcc needs to be asked to not screw up with stack > > > size. > > What happens when you drop all the noinlines for this? I assume > > this would alread make it faster. And now that we have bigger > > stacks we can likely tolerate it. > > %pV recurses through these code

Re: [PATCH] proc: faster /proc/*/status

2016-08-07 Thread Joe Perches
On Sun, 2016-08-07 at 09:59 -0700, Andi Kleen wrote: > > And then what? Parsing format string is still be there. > Perhaps could have a fast path for simple cases. > > > > This is first line of profile of the first function (format_decode) > > > >    │ static noinline_for_stack > >   

Re: [PATCH] proc: faster /proc/*/status

2016-08-07 Thread Joe Perches
On Sun, 2016-08-07 at 09:59 -0700, Andi Kleen wrote: > > And then what? Parsing format string is still be there. > Perhaps could have a fast path for simple cases. > > > > This is first line of profile of the first function (format_decode) > > > >    │ static noinline_for_stack > >   

Re: [PATCH] proc: faster /proc/*/status

2016-08-07 Thread Andi Kleen
> And then what? Parsing format string is still be there. Perhaps could have a fast path for simple cases. > > This is first line of profile of the first function (format_decode) > >│ static noinline_for_stack >│ int format_decode(const char *fmt, struct printf_spec

Re: [PATCH] proc: faster /proc/*/status

2016-08-07 Thread Andi Kleen
> And then what? Parsing format string is still be there. Perhaps could have a fast path for simple cases. > > This is first line of profile of the first function (format_decode) > >│ static noinline_for_stack >│ int format_decode(const char *fmt, struct printf_spec

Re: [PATCH] proc: faster /proc/*/status

2016-08-07 Thread Alexey Dobriyan
On Sat, Aug 06, 2016 at 08:16:27PM -0700, Andi Kleen wrote: > Alexey Dobriyan writes: > > - > > + seq_printf(m, "State:\t%s", get_task_state(p)); > > + > > + seq_puts(m, "\nTgid:\t"); > > The only different should be the format string. > > Scanning the format string

Re: [PATCH] proc: faster /proc/*/status

2016-08-07 Thread Alexey Dobriyan
On Sat, Aug 06, 2016 at 08:16:27PM -0700, Andi Kleen wrote: > Alexey Dobriyan writes: > > - > > + seq_printf(m, "State:\t%s", get_task_state(p)); > > + > > + seq_puts(m, "\nTgid:\t"); > > The only different should be the format string. > > Scanning the format string really shouldn't be that

Re: [PATCH] proc: faster /proc/*/status

2016-08-06 Thread Andi Kleen
Alexey Dobriyan writes: > - > + seq_printf(m, "State:\t%s", get_task_state(p)); > + > + seq_puts(m, "\nTgid:\t"); The only different should be the format string. Scanning the format string really shouldn't be that expensive?!? It would be better if you could find

Re: [PATCH] proc: faster /proc/*/status

2016-08-06 Thread Andi Kleen
Alexey Dobriyan writes: > - > + seq_printf(m, "State:\t%s", get_task_state(p)); > + > + seq_puts(m, "\nTgid:\t"); The only different should be the format string. Scanning the format string really shouldn't be that expensive?!? It would be better if you could find out why that is slow

Re: [PATCH] proc: faster /proc/*/status

2016-08-06 Thread Joe Perches
On Sat, 2016-08-06 at 15:56 +0300, Alexey Dobriyan wrote: > top(1) opens the following files for every PID: > > /proc/*/stat > /proc/*/statm > /proc/*/status > > This patch switches /proc/*/status away from seq_printf(). > The result is 13.5% speedup. If this is really an

Re: [PATCH] proc: faster /proc/*/status

2016-08-06 Thread Joe Perches
On Sat, 2016-08-06 at 15:56 +0300, Alexey Dobriyan wrote: > top(1) opens the following files for every PID: > > /proc/*/stat > /proc/*/statm > /proc/*/status > > This patch switches /proc/*/status away from seq_printf(). > The result is 13.5% speedup. If this is really an