linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@logfs.org>
To: Richard Kennedy <richard@rsk.demon.co.uk>
Cc: Christoph Lameter <cl@linux-foundation.org>,
	penberg <penberg@cs.helsinki.fi>, mpm <mpm@selenic.com>,
	linux-mm <linux-mm@kvack.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] slub: reduce total stack usage of slab_err & object_err
Date: Wed, 1 Oct 2008 12:32:25 +0200	[thread overview]
Message-ID: <20081001103224.GB31146@logfs.org> (raw)
In-Reply-To: <1222855567.3052.31.camel@castor.localdomain>

On Wed, 1 October 2008 11:06:07 +0100, Richard Kennedy wrote:
> 
> No I haven't made it available as it's really only a proof of concept,
> and I still don't have any sensible ideas how to deal with pointers to
> functions. Plus I'm still testing it to see if the results are anything
> like reasonable.
> Also it's finding lots of potentially recursive code paths and my
> heuristic to deal with them is very basic. I'm just adding a feature so
> that I can ignore some code paths, so maybe that will help.

Sounds very familiar. ;)

Function pointers are fairly easy.  When a function pointer is part of a
structure, simply consider that pointer to be a pseudo-function that
doesn't consume any stack space.  Whenever that pointer is written to,
that value can be "called" from the pseudo-function.  Callback functions
that are passed as function parameters can be handles similarly.

Getting this information wasn't too hard with smatch, but smatch depends
on gcc 3.1, which has *ahem* matured a bit.

Recursions essentially consume an infinite amount of stack unless you
know the upper bound for them.  I handled this two-fold.  First, every
single recursion is reported.  Secondly, every recursion is assumed to
be taken exactly once when calculating stack consumption.  This is the
minimal sane value.  Feel free to pick two or three if you prefer.

The main function code was done in two stages, iirc.  First stage simply
creates the call graph in memory.  Somewhere in the range of a million
objects.  Then I collapsed the graph from the leaves.  If function A
calls functions B, C and D, you first throw away two of the called
functions and keep the one with the biggest stack footprint.  Then A is
turned into a function A' that has the combined stack footprint of A and
B (assuming C and D are lighter) and is a leaf function.  Add some
annotation that B is called, along with anything B itself called before
it was collapsed.

If you use this method, recursions will sooner or later turn into a
pattern where A calls A.  Trivial to detect.

Maybe my thesis has a few more details:
http://wh.fh-wedel.de/~joern/quality.pdf

JA?rn

-- 
Joern's library part 13:
http://www.chip-architect.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2008-10-01 10:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-30 15:15 Richard Kennedy
2008-09-30 15:32 ` Matt Mackall
2008-09-30 15:38 ` Christoph Lameter
2008-09-30 15:49   ` Matt Mackall
2008-09-30 16:20   ` Richard Kennedy
2008-09-30 16:43     ` Matt Mackall
2008-09-30 17:36     ` Christoph Lameter
2008-09-30 17:37     ` Matt Mackall
2008-09-30 18:33       ` Matt Mackall
2008-10-01  9:50         ` Richard Kennedy
2008-10-01  0:02     ` Matt Mackall
2008-09-30 19:33 ` Jörn Engel
2008-10-01 10:06   ` Richard Kennedy
2008-10-01 10:32     ` Jörn Engel [this message]

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=20081001103224.GB31146@logfs.org \
    --to=joern@logfs.org \
    --cc=cl@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mpm@selenic.com \
    --cc=penberg@cs.helsinki.fi \
    --cc=richard@rsk.demon.co.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox