Hi Marcelo,
Few of the product groups are running into stack overflow problems
on latest 2.4 distribution releases, especially on z-Series.
While poking thro the 2.4 code, I realized the 2.6 stack reduction
work did not get merged into 2.4.
Biggest offender seems to be "struct linux_binprm" in do_execve().
Converting structure on the stack to malloc() (like 2.6 does)
solved majority of problems. There are other places, but savings
are smaller. (But after bunch of changes, we were able to reduce
stack by 1K).
I am wondering, if there is any interest in merging stack reduction
patches into 2.4 mainline ? If so, I will rework the patches on
latest 2.4 and submit them.
Thanks,
Badari
On Fri, Jan 07, 2005 at 07:48:06AM -0800, Badari Pulavarty wrote:
> Hi Marcelo,
Hi Badari,
> Few of the product groups are running into stack overflow problems
> on latest 2.4 distribution releases, especially on z-Series.
Lets try to minimize the problems.
> While poking thro the 2.4 code, I realized the 2.6 stack reduction
> work did not get merged into 2.4.
>
> Biggest offender seems to be "struct linux_binprm" in do_execve().
> Converting structure on the stack to malloc() (like 2.6 does)
> solved majority of problems. There are other places, but savings
> are smaller. (But after bunch of changes, we were able to reduce
> stack by 1K).
I think the bigger offenders should be fixed. I suppose most of these
changes are not very intrusive and are acceptable for v2.4.
What are the "other places" that you have fixed? And for how much of
"1K savings" they account for?
> I am wondering, if there is any interest in merging stack reduction
> patches into 2.4 mainline ? If so, I will rework the patches on
> latest 2.4 and submit them.
Please submit them to LKML for peer view - thanks!
On Fri, 2005-01-07 at 06:12, Marcelo Tosatti wrote:
> On Fri, Jan 07, 2005 at 07:48:06AM -0800, Badari Pulavarty wrote:
> > Hi Marcelo,
>
> Hi Badari,
>
> > Few of the product groups are running into stack overflow problems
> > on latest 2.4 distribution releases, especially on z-Series.
>
> Lets try to minimize the problems.
>
> > While poking thro the 2.4 code, I realized the 2.6 stack reduction
> > work did not get merged into 2.4.
> >
> > Biggest offender seems to be "struct linux_binprm" in do_execve().
> > Converting structure on the stack to malloc() (like 2.6 does)
> > solved majority of problems. There are other places, but savings
> > are smaller. (But after bunch of changes, we were able to reduce
> > stack by 1K).
>
> I think the bigger offenders should be fixed. I suppose most of these
> changes are not very intrusive and are acceptable for v2.4.
No. Changes are to malloc() instead of stack structures and fail,
if malloc() fails.
>
> What are the "other places" that you have fixed? And for how much of
> "1K savings" they account for?
Here are the changes and savings.
do_execve 320
number 100
nfs_lookup 184
nfs_cached_lookup 88
__revalidate_inode 112
rpc_call_sync 144
xprt_sendmsg 120
>
> > I am wondering, if there is any interest in merging stack reduction
> > patches into 2.4 mainline ? If so, I will rework the patches on
> > latest 2.4 and submit them.
>
> Please submit them to LKML for peer view - thanks!
Here is the single crude patch for one of the distro releases.
(may not apply to latest 2.4 mainline).
Please let me know, if you like these changes - I will make smaller
patches (one for each area) to current 2.4 mainline, test it and
send it.
Thanks,
Badari
fr den 07.01.2005 Klokka 13:42 (-0800) skreiv Badari Pulavarty:
> Here are the changes and savings.
>
> do_execve 320
> number 100
> nfs_lookup 184
> nfs_cached_lookup 88
> __revalidate_inode 112
> rpc_call_sync 144
> xprt_sendmsg 120
There is no nfs_cached_lookup() in the mainline 2.4 tree. That is part
of the READDIRPLUS code, and was therefore never merged.
You're better off using rpc_new_task() in rpc_call_sync(): no kfree()
required, and no rpc_init_task() required.
Cheers,
Trond
--
Trond Myklebust <[email protected]>
On Fri, 2005-01-07 at 14:40, Trond Myklebust wrote:
> fr den 07.01.2005 Klokka 13:42 (-0800) skreiv Badari Pulavarty:
>
> > Here are the changes and savings.
> >
> > do_execve 320
> > number 100
> > nfs_lookup 184
> > nfs_cached_lookup 88
> > __revalidate_inode 112
> > rpc_call_sync 144
> > xprt_sendmsg 120
>
> There is no nfs_cached_lookup() in the mainline 2.4 tree. That is part
> of the READDIRPLUS code, and was therefore never merged.
Like I mentioned earlier, this patch was done for a distro release
not mainline. I need to look at mainline code.
>
> You're better off using rpc_new_task() in rpc_call_sync(): no kfree()
> required, and no rpc_init_task() required.
Sure. Will do.
Thanks,
Badari
On Fri, 2005-01-07 at 14:40, Trond Myklebust wrote:
>
> You're better off using rpc_new_task() in rpc_call_sync(): no kfree()
> required, and no rpc_init_task() required.
>
Hmm.. I am trying to do this. Just wanted to double check.
If I don't do kfree(), its gets automatically freed up thro
rpc_release_task() correct ?
Thanks,
Badari
fr den 07.01.2005 Klokka 16:55 (-0800) skreiv Badari Pulavarty:
> On Fri, 2005-01-07 at 14:40, Trond Myklebust wrote:
>
> >
> > You're better off using rpc_new_task() in rpc_call_sync(): no kfree()
> > required, and no rpc_init_task() required.
> >
>
> Hmm.. I am trying to do this. Just wanted to double check.
>
> If I don't do kfree(), its gets automatically freed up thro
> rpc_release_task() correct ?
Yes.
--
Trond Myklebust <[email protected]>
> Here is the single crude patch for one of the distro releases.
> (may not apply to latest 2.4 mainline).
+ if (!bprmp) {
+ retval = -ENOMEM;
+ return retval;
+ }
You can just return -ENOMEM...
--
vda