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
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
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
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
> > > 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
> > > 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
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
> >
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
> >
> 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
> 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
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
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
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
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
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
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
16 matches
Mail list logo