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..."
prev parent 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®