public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yum Rayan <yum.rayan@gmail.com>
To: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
Cc: "Jörn Engel" <joern@wohnheim.fh-wedel.de>,
	linux-kernel@vger.kernel.org, linux-pcmcia@lists.infradead.org,
	dahinds@users.sourceforge.net, rddunlap@osdl.org
Subject: Re: [PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event()
Date: Tue, 26 Apr 2005 00:18:54 -0700	[thread overview]
Message-ID: <df35dfeb05042600184c683c8c@mail.gmail.com> (raw)
In-Reply-To: <200504231821.31309.vda@port.imtp.ilyichevsk.odessa.ua>

On 4/23/05, Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> 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

  reply	other threads:[~2005-04-26  7:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-21 22:02 [PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event() Yum Rayan
2005-04-21 22:12 ` [PATCH linux-2.6.12-rc2-mm3] serial_cs: Reduce stack usage in serial_event() Yum Rayan
2005-04-22  8:22 ` [PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event() Denis Vlasenko
2005-04-23  0:12   ` Jörn Engel
2005-04-23 15:21     ` Denis Vlasenko
2005-04-26  7:18       ` Yum Rayan [this message]
2005-04-26  9:46       ` Jörn Engel

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=df35dfeb05042600184c683c8c@mail.gmail.com \
    --to=yum.rayan@gmail.com \
    --cc=dahinds@users.sourceforge.net \
    --cc=joern@wohnheim.fh-wedel.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pcmcia@lists.infradead.org \
    --cc=rddunlap@osdl.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox