All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Joe Perches <joe@perches.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk
Subject: Re: [PATCH] proc: faster /proc/*/status
Date: Tue, 9 Aug 2016 16:25:04 -0700	[thread overview]
Message-ID: <20160809162504.2db8051c15afd5618c4b7d7e@linux-foundation.org> (raw)
In-Reply-To: <1470604951.28648.44.camel@perches.com>

On Sun, 07 Aug 2016 14:22:31 -0700 Joe Perches <joe@perches.com> 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 alread make it faster. And now that we have bigger
> > > > stacks we can likely tolerate it.
> > > %pV recurses through these code paths.
> > > I believe the maximum current recursion depth is 3.
> > I assume 2 max would sufficient for all users in kernel.
> > 
> > And perhaps it would be better to get rid of "features" like this,
> > and instead focus on more common cases.
> 
> It'd be a dubious trade-off in my opinion.
> 
> Overall code size has been reduced by hundreds of KB
> by using %pV.

I kinda like Alexey's patch just for aesthetic reasons.  Those huge
straggly printk-style statements are a real pain to maintain, trying to
keep the control string and the args in sync.  Especially when there are
ifdefs everywhere - take a look at meminfo_proc_show() and weep.  Geeze
the number of times I've had to maintain (and screw up) conflicts in
that thing...

  reply	other threads:[~2016-08-09 23:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-06 12:56 [PATCH] proc: faster /proc/*/status Alexey Dobriyan
2016-08-06 22:41 ` Joe Perches
2016-08-09  3:02   ` [PATCH] seq/proc: Modify seq_put_decimal_[u]ll to take a const char *, not char Joe Perches
2016-08-07  3:16 ` [PATCH] proc: faster /proc/*/status Andi Kleen
2016-08-07  8:53   ` Alexey Dobriyan
2016-08-07 16:59     ` Andi Kleen
2016-08-07 17:39       ` Joe Perches
2016-08-07 17:44         ` Andi Kleen
2016-08-07 21:22           ` Joe Perches
2016-08-09 23:25             ` Andrew Morton [this message]
2016-08-10  6:38               ` [RFC PATCH] meminfo: Break apart a very long seq_printf with #ifdefs Joe Perches
2016-08-11 21:50                 ` Andrew Morton
2016-08-11 21:57                   ` Joe Perches

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=20160809162504.2db8051c15afd5618c4b7d7e@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=adobriyan@gmail.com \
    --cc=andi@firstfloor.org \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.