Date: Wed, 9 Jun 2004 20:53:32 +0200
From: =?iso-8859-1?Q?J=F6rn?= Engel <joern@wohnheim.fh-wedel.de>
To: Chris Mason <mason@suse.com>
Cc: Hans Reiser <reiser@namesys.com>, reiserfs-dev@namesys.com,
       linux-kernel@vger.kernel.org
Subject: Re: [STACK] >3k call path in reiserfs
Message-ID: <20040609185332.GF2950@wohnheim.fh-wedel.de>
References: <20040609122226.GE21168@wohnheim.fh-wedel.de> <1086784264.10973.236.camel@watt.suse.com> <1086800028.10973.258.camel@watt.suse.com> <40C74388.20301@namesys.com> <20040609172843.GB2950@wohnheim.fh-wedel.de> <40C75273.7020508@namesys.com> <1086806933.10973.299.camel@watt.suse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1086806933.10973.299.camel@watt.suse.com>
User-Agent: Mutt/1.3.28i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 915
Lines: 24

On Wed, 9 June 2004 14:48:54 -0400, Chris Mason wrote:
> 
> It's pretty important, especially when you toss NFS into the call path
> the stack usage can go higher.  The switch to kmalloc will be relatively
> small and by now we're good at testing for schedule bugs.

How can that happen?  Ignoring recursions, the data given should
already be the theoretical maximum.  Otherwise, please show me where
my tool makes a non-pessimistic choice.

[ Actually, I still miss callback functions.  Known bug. ]

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..."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/