All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Peter Osterlund <petero2@telia.com>
Cc: Phillip Susi <psusi@cfl.rr.com>, linux-kernel@vger.kernel.org
Subject: Re: pktcdvd stack usage regression
Date: Fri, 10 Feb 2006 15:39:47 +0100	[thread overview]
Message-ID: <20060210143947.GE19918@stusta.de> (raw)
In-Reply-To: <m3lkwl6pfu.fsf@telia.com>

On Thu, Feb 09, 2006 at 07:01:25AM +0100, Peter Osterlund wrote:
> Adrian Bunk <bunk@stusta.de> writes:
> 
> > Hi Phillip,
> > 
> > your recent patch "pktcdvd: Allow larger packets" changed 
> > PACKET_MAX_SIZE in the pktcdvd driver from 32 to 128.
> > 
> > Unfortunately, drivers/block/pktcdvd.c contains the following:
> > 
> > <--  snip  -->
> > 
> > ...
> > static void pkt_start_write(struct pktcdvd_device *pd, struct 
> > packet_data *pkt)
> > {
> >         struct bio *bio;
> >         struct page *pages[PACKET_MAX_SIZE];
> >         int offsets[PACKET_MAX_SIZE];
> > ...
> > 
> > <--  snip  -->
> > 
> > With PACKET_MAX_SIZE=128, this allocates more than 1 kB on the stack 
> 
> Yes, I know.
> 
> > which is not acceptable considering that we might have only 4 kB stack 
> > altogether.
> 
> Why is it not acceptable? The pkt_start_write() function is only
> called from the kcdrwd() kernel thread and the pkt_start_write()
> function doesn't call anything else in the kernel that could require
> lots of stack space.
> 
> The actual I/O is started from pkt_iosched_process_queue(), which
> calls generic_make_request(). However pkt_iosched_process_queue() is
> on a different call chain than pkt_start_write(), so I don't see how
> this could be a problem.

You might be able to verify this is true today, but it is a bit fragile 
and other changes might always add even more stack usage in some places. 
Therefore, functions using 1 kB stack aren't a good idea.

As an exercise, pkt_open() currently uses more than 0,5 kB stack
(kernel 2.6.16-rc2-mm1, i386, gcc 4.0). Try to understand where this 
stack usage comes from (hint: add up the stack usages of all only once 
used static functions gcc automatically inlines).

> Peter Osterlund

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2006-02-10 14:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-09  2:09 pktcdvd stack usage regression Adrian Bunk
2006-02-09  6:01 ` Peter Osterlund
2006-02-10 14:39   ` Adrian Bunk [this message]
2006-02-10 20:56     ` Peter Osterlund

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=20060210143947.GE19918@stusta.de \
    --to=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=petero2@telia.com \
    --cc=psusi@cfl.rr.com \
    /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.