All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Randy.Dunlap" <rddunlap@osdl.org>
To: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
	Arjan van de Ven <arjan@infradead.org>,
	Andreas Dilger <adilger@clusterfs.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] reduce stack usage of NFS (was Re: How to safely reduce...)
Date: Fri, 29 Oct 2004 20:01:31 -0700	[thread overview]
Message-ID: <4183040B.3030201@osdl.org> (raw)
In-Reply-To: <200410300059.06497.vda@port.imtp.ilyichevsk.odessa.ua>

Denis Vlasenko wrote:
>>>>I can convert these into kmalloc'ed variants but hesitate to do so
>>>>because of possible 'need to kmalloc in order to free memory for kmalloc'
>>>>deadlocks.
>>>
>>>how about a memory pool?
>>>
>>>It's not THE solution but I suspect the depth of callchains of these isn't too deep so it would work
>>
>>I can't see that any of the callchains Denis listed can deadlock. None
>>of them appear to lie in the memory reclaim paths.
> 
> 
> This patch reduces stack usage to below 100 bytes for
> the following functions:
> 
>                        stack usage in 2.6.9
> nfs3_proc_create:             544
> _nfs4_do_open:                516
> nfs_readdir:                  412
> nfs_symlink:                  368
> _nfs4_open_delegation_recall: 368
> nfs3_proc_rename:             364
> _nfs4_open_reclaim:           364
> nfs_mknod:                    352
> nfs_mkdir:                    352
> nfs_proc_create:              344
> nfs3_proc_link:               328
> nfs_lookup_revalidate:        312
> nfs_lookup:                   292
> 
> (btw: in function nfs_readdir: local variable 'desc' seem to be
> easily replaceable with &my_desc, or am I missing something?)
> 
> Compile tested only. I can't run test it until next Wednesday :(
> 
> Please review, especially for leaks on error paths.

Hi Denis,
I checked all of it.  Looks right & it builds.

-- 
~Randy

  reply	other threads:[~2004-10-30  3:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-28 21:20 How to safely reduce stack usage in nfs code? Denis Vlasenko
2004-10-29  0:15 ` Andreas Dilger
2004-10-29  9:01 ` Arjan van de Ven
2004-10-29 14:20   ` Trond Myklebust
2004-10-29 21:59     ` [PATCH] reduce stack usage of NFS (was Re: How to safely reduce...) Denis Vlasenko
2004-10-30  3:01       ` Randy.Dunlap [this message]
2004-10-30  9:23         ` Denis Vlasenko
2004-11-01 20:57       ` Trond Myklebust

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=4183040B.3030201@osdl.org \
    --to=rddunlap@osdl.org \
    --cc=adilger@clusterfs.com \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /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.