All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Alasdair G Kergon <agk@redhat.com>
Subject: stack overflow on Sparc64
Date: Wed, 18 Jun 2008 00:47:57 +0000	[thread overview]
Message-ID: <Pine.LNX.4.64.0806171954060.2560@engineering.redhat.com> (raw)

Hi

I am getting stack overflows on my Sparc64 station. They happen when I 
copy to device-mapper snapshot origin device using small IO size (512 
bytes) and simultaneously execute "lvs" command. The kernel is compiled 
with most debugging functions enabled. The stack trace is this:

__ide_end_request
__blk_end_request
__end_that_request_first
req_bio_endio
bio_endio
clone_endio
dec_pending
bio_endio
clone_endio
dec_pending
bio_endio
clone_endio
dec_pending
bio_endio
end_bio_bh_io_sync
end_buffer_read_sync
__end_buffer_read_notouch
unlock_buffer
wake_up_bit
__wake_up_bit
__wake_up
__wake_up_common
wake_bit_function
autoremove_wake_function
default_wake_function
try_to_wake_up
task_rq_lock
__spin_lock
lock_acquire
__lock_acquire
*** crash, stack overflow

--- observations:

That loop bio_endio->clone_endio->dec_pending is repeating for each level 
of nested devices --- so for any architecture there exists a level at 
which it causes trouble. We need something to prevent recursion, maybe the 
similar trick that was done with avoing bio request function recursion 
(i.e. if bio_endio is called recursively, it just adds the bio to queue 
and lets the top level to call endio method).

Wait queue waking looks like being written by a high-level maniac --- it 
contains 8 levels of calls (none of them inlined). 7 of these calls (until 
try_to_wake_up) do nothing but pass arguments to lower level call. And 
each of these calls allocate at least 192 bytes of stack space. All these 
7 useless calls consume 1360 bytes of stack (and cause windows traps that 
needlessly damage performance). Would you agree to inline most of the 
calls to save stack? Or do you see another solution?

Long-term consideration: Is it possible to implement interrupt stacks on 
sparc64? Functions on sparc eat stack much more aggressively than on other 
architectures (minimum stack size for a function is 192 bytes).

Mikulas

WARNING: multiple messages have this Message-ID (diff)
From: Mikulas Patocka <mpatocka@redhat.com>
To: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Alasdair G Kergon <agk@redhat.com>
Subject: stack overflow on Sparc64
Date: Tue, 17 Jun 2008 20:47:57 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0806171954060.2560@engineering.redhat.com> (raw)

Hi

I am getting stack overflows on my Sparc64 station. They happen when I 
copy to device-mapper snapshot origin device using small IO size (512 
bytes) and simultaneously execute "lvs" command. The kernel is compiled 
with most debugging functions enabled. The stack trace is this:

__ide_end_request
__blk_end_request
__end_that_request_first
req_bio_endio
bio_endio
clone_endio
dec_pending
bio_endio
clone_endio
dec_pending
bio_endio
clone_endio
dec_pending
bio_endio
end_bio_bh_io_sync
end_buffer_read_sync
__end_buffer_read_notouch
unlock_buffer
wake_up_bit
__wake_up_bit
__wake_up
__wake_up_common
wake_bit_function
autoremove_wake_function
default_wake_function
try_to_wake_up
task_rq_lock
__spin_lock
lock_acquire
__lock_acquire
*** crash, stack overflow

--- observations:

That loop bio_endio->clone_endio->dec_pending is repeating for each level 
of nested devices --- so for any architecture there exists a level at 
which it causes trouble. We need something to prevent recursion, maybe the 
similar trick that was done with avoing bio request function recursion 
(i.e. if bio_endio is called recursively, it just adds the bio to queue 
and lets the top level to call endio method).

Wait queue waking looks like being written by a high-level maniac --- it 
contains 8 levels of calls (none of them inlined). 7 of these calls (until 
try_to_wake_up) do nothing but pass arguments to lower level call. And 
each of these calls allocate at least 192 bytes of stack space. All these 
7 useless calls consume 1360 bytes of stack (and cause windows traps that 
needlessly damage performance). Would you agree to inline most of the 
calls to save stack? Or do you see another solution?

Long-term consideration: Is it possible to implement interrupt stacks on 
sparc64? Functions on sparc eat stack much more aggressively than on other 
architectures (minimum stack size for a function is 192 bytes).

Mikulas

             reply	other threads:[~2008-06-18  0:47 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-18  0:47 Mikulas Patocka [this message]
2008-06-18  0:47 ` stack overflow on Sparc64 Mikulas Patocka
2008-06-18  4:01 ` David Miller
2008-06-18  4:01   ` David Miller
2008-06-19  3:24   ` Mikulas Patocka
2008-06-19  3:24     ` Mikulas Patocka
2008-06-19  3:59     ` David Miller
2008-06-19  3:59       ` David Miller
2008-06-19  5:17       ` Mikulas Patocka
2008-06-19  5:17         ` Mikulas Patocka
2008-06-19  6:37         ` David Miller
2008-06-19  6:37           ` David Miller
2008-06-19 13:01           ` Mikulas Patocka
2008-06-19 13:01             ` Mikulas Patocka
2008-06-20 15:47   ` Mikulas Patocka
2008-06-20 15:47     ` Mikulas Patocka
2008-06-20 17:26     ` David Miller
2008-06-20 17:26       ` David Miller
2008-06-20 20:34       ` Mikulas Patocka
2008-06-20 20:34         ` Mikulas Patocka
2008-06-20 20:37         ` David Miller
2008-06-20 20:37           ` David Miller
2008-06-20 21:26           ` Mikulas Patocka
2008-06-20 21:26             ` Mikulas Patocka
2008-06-20 21:41             ` David Miller
2008-06-20 21:41               ` David Miller
2008-06-21  4:51               ` David Miller
2008-06-21  4:51                 ` David Miller
2008-06-21 19:42                 ` Mikulas Patocka
2008-06-21 19:42                   ` Mikulas Patocka
2008-06-22  7:03                   ` David Miller
2008-06-22  7:03                     ` David Miller
2008-06-22 13:48                     ` Mikulas Patocka
2008-06-22 13:48                       ` Mikulas Patocka
2008-08-12  6:30                   ` David Miller
2008-08-12  6:30                     ` David Miller
2008-08-12  8:22                     ` David Miller
2008-08-12  8:22                       ` David Miller
2008-08-13  0:53                       ` Mikulas Patocka
2008-08-13  0:53                         ` Mikulas Patocka
2008-08-13  0:59                         ` David Miller
2008-08-13  0:59                           ` David Miller
2008-08-13  1:11                     ` console handover badness [was: stack overflow on Sparc64] Mikulas Patocka
2008-08-13  1:11                       ` Mikulas Patocka
2008-08-13  1:22                       ` console handover badness David Miller
2008-08-13  1:22                         ` David Miller
2008-08-13  1:40                       ` David Miller
2008-08-13  1:40                         ` David Miller
2008-08-13  8:50                         ` David Miller
2008-08-13  8:50                           ` David Miller
2008-08-13 12:46                         ` Mikulas Patocka
2008-08-13 12:46                           ` Mikulas Patocka
2008-08-14  3:25                           ` David Miller
2008-08-14  3:25                             ` David Miller
2008-08-14 23:11                             ` Bootmem allocator broken [was: console handover badness] Mikulas Patocka
2008-08-14 23:11                               ` Mikulas Patocka
2008-08-14 23:25                               ` Bootmem allocator broken David Miller
2008-08-14 23:25                                 ` David Miller
2008-08-15 11:09                                 ` Alexander Beregalov
2008-08-15 11:09                                   ` Alexander Beregalov
2008-08-15 21:13                                   ` David Miller
2008-08-15 21:13                                     ` David Miller
2008-08-14 23:40                               ` Johannes Weiner
2008-08-14 23:40                                 ` Johannes Weiner
2008-06-20 21:14       ` stack overflow on Sparc64 Mikulas Patocka
2008-06-20 21:14         ` Mikulas Patocka
2008-06-20 21:20         ` David Miller
2008-06-20 21:20           ` David Miller
2008-06-20 21:25           ` Mikulas Patocka
2008-06-20 21:25             ` Mikulas Patocka
2008-06-20 21:44             ` David Miller
2008-06-20 21:44               ` David Miller
2008-06-20 21:47               ` David Miller
2008-06-20 21:47                 ` David Miller
2008-06-20 22:22                 ` Mikulas Patocka
2008-06-20 22:22                   ` Mikulas Patocka
2008-06-20 22:28                   ` David Miller
2008-06-20 22:28                     ` David Miller
2008-06-20 22:36                     ` Mikulas Patocka
2008-06-20 22:36                       ` Mikulas Patocka
2008-06-20 22:47                       ` David Miller
2008-06-20 22:47                         ` David Miller
2008-06-21  0:37                         ` Mikulas Patocka
2008-06-21  0:37                           ` Mikulas Patocka
2008-06-20 22:33               ` Mikulas Patocka
2008-06-20 22:33                 ` Mikulas Patocka

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=Pine.LNX.4.64.0806171954060.2560@engineering.redhat.com \
    --to=mpatocka@redhat.com \
    --cc=agk@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sparclinux@vger.kernel.org \
    /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.