Re: [PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event()

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event()

Yum Rayan
On 4/23/05, Denis Vlasenko <[hidden email]> wrote:

> On Saturday 23 April 2005 03:12, Jörn Engel wrote:
>
> > > 1) struct is unnamed and local to function
> > > 2) Variables do not change their type, the just sit in local-> now.
> > >    I can just add 'local->' to each affected variable,
> > >    without "it was an object, now it is a pointer" changes.
> > >    No need to replace . with ->, remove &, etc.
> >
> > I'd have proposed the same, before reading further down in the patch.
> > Basically, the driver is full of duplication, so the exact same struct
> > can be used several times.  Therefore, the downsides of your approach
> > seem to prevail.
>
> What downsides? I must admit I do not understand your answer here.
>
> Let me stay on the subject of converting large stack onjects
> to kmalloc()ed ones, without reference to current state
> of code in a particular module.
>
> Basically, these objects are local to function. We do not

And seem to be always used in conjuction with each other, not alone
across various functions in this driver alone but also across various
card services drivers.

> introduce struct as an 'object'. It merely aggregates
> all locals we decided to move to kmalloc space,
> only because it's easier that way to allocate and reference
> all of them in C.
>
> Thus, even if there are many functions with similar
> set of locals, it makes little sense to declare common struct.
> IOW, I wouldn't do this:
>
> struct big {
>        large_t large;
>        huge_t huge;
> };
>
> int f() {
>        struct big *local;
>        local = kmalloc(sizeof(big),...);
>        ...
> }
>
> int g() {
>        struct big *local;
>        local = kmalloc(sizeof(big),...);
>        ...
> }
>
> For one, what will happen when you will need to add
> another local in one function only?

struct another_local_struct *another_local;
another_local = kmalloc(sizeof(sruct another_local_struct),...);

or if single kmalloc is preferred, then:

struct another_big_struct {
  struct old_big_struct old_big;
  struct new_big_struct new_big;
} ;

I'd agree with your suggestion had it been "struct big", or "struct
huge" or "struct stack" or something like that, but does not seem
appropriate in this particular case.

Regards,
Rayan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event()

Jörn Engel
On Sat, 23 April 2005 18:21:30 +0300, Denis Vlasenko wrote:

> On Saturday 23 April 2005 03:12, Jörn Engel wrote:
>
> > > 1) struct is unnamed and local to function
> > > 2) Variables do not change their type, the just sit in local-> now.
> > >    I can just add 'local->' to each affected variable,
> > >    without "it was an object, now it is a pointer" changes.
> > >    No need to replace . with ->, remove &, etc.
> >
> > I'd have proposed the same, before reading further down in the patch.
> > Basically, the driver is full of duplication, so the exact same struct
> > can be used several times.  Therefore, the downsides of your approach
> > seem to prevail.
>
> What downsides? I must admit I do not understand your answer here.

1. Read the patch.  All of it.

2. Virtually the same identical variables are stuffed into the stack
frames of:
o mhz_mfc_config,
o mhz_setup,
o mot_setup,
o smc_setup,
o osi_setup and
o smc91c92_config.

That is six functions.  If it were just one, I would definitely agree
with you.  For two functions, well, it wouldn't really matter either
way.  But should six functions all copy the exact same struct six
different times instead of referencing a single globally defined one?
Naa, that's barely an advantage.

> Instead, I'd do it like I described in previous mail:

If you would actually like to do something, please provide further
patches to that driver.  It sucks.  It sucks so bad, that it's hardly
possible to change anything without improving it.  There are much
grosser things to clean up than the one we're discussing right now.

Jörn

--
He who knows others is wise.
He who knows himself is enlightened.
-- Lao Tsu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/