mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Steve Lord <lord@xfs.org>
Cc: nathans@sgi.com, linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: [STACK] >3k call path in xfs
Date: Wed, 9 Jun 2004 18:03:15 +0200	[thread overview]
Message-ID: <20040609160315.GA29531@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <40C72746.8060603@xfs.org>

On Wed, 9 June 2004 10:05:42 -0500, Steve Lord wrote:
> Jörn Engel wrote:
> >xfs is quite interesting.  No single function is particularly
> >stack-hungry, but the sheer depth of the call path adds up.  Nathan,
> >can you see if some bytes can be saved here and there?
> >
> >3k is not really bad yet, I just like to keep 1k of headroom for
> >surprises like an extra int foo[256] in a structure.
> 
> Are you doing some form of call chain analysis to arrive
> at this stack?

Yup.

> Actually this one is impossible, the function xfs_bmapi is
> confusing you analyser, it is used for read and write
> calls to map from file offsets to disk blocks. The path
> you chased down from xfs_bmapi is doing a realtime
> allocation, the swapext call does not do allocations,
> it is in this case looking up the contents of an acl
> for a permission check - xfs_bmapi in this case will
> not call much of anything.

Ack.  Clearly some sort of semantical checking would be nice to have,
but for the moment, we still need humans to do that job.  Thanks!

> Once it gets to schedule it is  a little out of XFS's hands what
> happens, or which stack is actually in use. I think the
> path you followed out of schedule is the cleanup of the
> audit structure of a dead process - it is the one doing
> the panicing here. An xfs call into schedule to wait for
> I/O will not be going down that path.

Yes, same problem.

> I think you have to be careful looking at these call chains.

For sure.  But since I scale extremely badly, I try to distribute this
work.  Thanks for taking a share.

There are a few more spots worth looking at, though.  I have no idea,
how often the loops below can iterate, so they may cause problems as
well.  If they are harmless as well, xfs is in a good state wrt stack
usage.  Nice.

WARNING: trivial recursion detected:
      44  xfs_attr_node_inactive
WARNING: trivial recursion detected:
      24  xfs_bmap_count_tree
WARNING: recursion detected:
      56  xfs_map_unwritten
      60  xfs_convert_page
WARNING: recursion detected:
       0  xfs_iaccess
      16  xfs_acl_iaccess
     104  xfs_attr_fetch

Jörn

-- 
Public Domain  - Free as in Beer
General Public - Free as in Speech
BSD License    - Free as in Enterprise
Shared Source  - Free as in "Work will make you..."

      reply	other threads:[~2004-06-09 16:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-09 12:26 Jörn Engel
2004-06-09 12:54 ` Christian Borntraeger
2004-06-09 13:05   ` Jörn Engel
2004-06-09 13:10 ` Jörn Engel
2004-06-09 22:58   ` Nathan Scott
2004-06-09 15:05 ` Steve Lord
2004-06-09 16:03   ` 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=20040609160315.GA29531@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    --cc=lord@xfs.org \
    --cc=nathans@sgi.com \
    /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

all inboxes | Powered by JetHome®