From: Steven Rostedt <rostedt@goodmis.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Paul Mackerras <paulus@samba.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
linuxppc-dev@ozlabs.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Large stack usage in fs code (especially for PPC64)
Date: Mon, 17 Nov 2008 15:59:56 -0500 (EST) [thread overview]
Message-ID: <alpine.DEB.1.10.0811171557370.26123@gandalf.stny.rr.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0811171508300.8722@gandalf.stny.rr.com>
On Mon, 17 Nov 2008, Steven Rostedt wrote:
>
> Note, I was using a default config that had CONFIG_IRQSTACKS off and
> CONFIG_PPC_64K_PAGES on.
Here's my stack after boot up with CONFIG_IRQSTACKS set. Seems that
softirqs still use the same stack as the process.
root@electra ~> cat /debug/tracing/stack_trace
Depth Size Location (59 entries)
----- ---- --------
0) 12384 192 ftrace_call+0x4/0x14
1) 12192 128 .sched_clock+0x20/0x60
2) 12064 128 .sched_clock_cpu+0x34/0x50
3) 11936 144 .cpu_clock+0x3c/0xa0
4) 11792 144 .get_timestamp+0x2c/0x50
5) 11648 144 .__touch_softlockup_watchdog+0x3c/0x60
6) 11504 192 .softlockup_tick+0xe4/0x220
7) 11312 128 .run_local_timers+0x34/0x50
8) 11184 160 .update_process_times+0x44/0xb0
9) 11024 176 .tick_sched_timer+0x8c/0x120
10) 10848 160 .__run_hrtimer+0xd8/0x130
11) 10688 240 .hrtimer_interrupt+0x16c/0x220
12) 10448 160 .timer_interrupt+0xcc/0x110
13) 10288 96 decrementer_common+0xe0/0x100
14) 10192 784 .ftrace_test_stop_func+0x4c/0x70
15) 9408 112 ftrace_call+0x4/0x14
16) 9296 144 .init_buffer_head+0x20/0x60
17) 9152 256 .cache_alloc_refill+0x5a0/0x740
18) 8896 160 .kmem_cache_alloc+0xfc/0x140
19) 8736 144 .alloc_buffer_head+0x3c/0xc0
20) 8592 176 .alloc_page_buffers+0xb0/0x130
21) 8416 160 .create_empty_buffers+0x44/0x1a0
22) 8256 1280 .block_read_full_page+0x3b0/0x430
23) 6976 144 .blkdev_readpage+0x38/0x60
24) 6832 176 .read_cache_page_async+0x124/0x230
25) 6656 160 .read_cache_page+0x50/0xe0
26) 6496 160 .read_dev_sector+0x58/0x100
27) 6336 272 .msdos_partition+0xa4/0x880
28) 6064 240 .rescan_partitions+0x1f0/0x430
29) 5824 208 .__blkdev_get+0x124/0x3d0
30) 5616 144 .blkdev_get+0x3c/0x60
31) 5472 192 .register_disk+0x194/0x1f0
32) 5280 160 .add_disk+0xe8/0x160
33) 5120 224 .sd_probe+0x2f0/0x440
34) 4896 176 .driver_probe_device+0x14c/0x380
35) 4720 144 .__device_attach+0x38/0x60
36) 4576 192 .bus_for_each_drv+0xb8/0x120
37) 4384 160 .device_attach+0x94/0xe0
38) 4224 144 .bus_attach_device+0x78/0xb0
39) 4080 240 .device_add+0x54c/0x730
40) 3840 160 .scsi_sysfs_add_sdev+0x7c/0x2e0
41) 3680 336 .scsi_probe_and_add_lun+0xb7c/0xc60
42) 3344 192 .__scsi_add_device+0x11c/0x150
43) 3152 176 .ata_scsi_scan_host+0x238/0x330
44) 2976 208 .ata_host_register+0x320/0x3c0
45) 2768 192 .ata_host_activate+0xf8/0x190
46) 2576 224 .mv_pci_init_one+0x284/0x430
47) 2352 160 .pci_device_probe+0x98/0xf0
48) 2192 176 .driver_probe_device+0x14c/0x380
49) 2016 160 .__driver_attach+0xd4/0x110
50) 1856 192 .bus_for_each_dev+0xa8/0x100
51) 1664 144 .driver_attach+0x40/0x60
52) 1520 192 .bus_add_driver+0x268/0x340
53) 1328 176 .driver_register+0x88/0x1d0
54) 1152 176 .__pci_register_driver+0x90/0x100
55) 976 144 .mv_init+0x38/0xa0
56) 832 544 .do_one_initcall+0x78/0x240
57) 288 192 .kernel_init+0x21c/0x2b0
58) 96 96 .kernel_thread+0x54/0x70
This is still 12K. Kind of big even for a 16K stack.
-- Steve
next prev parent reply other threads:[~2008-11-17 21:00 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-17 20:34 Large stack usage in fs code (especially for PPC64) Steven Rostedt
2008-11-17 20:59 ` Steven Rostedt [this message]
2008-11-17 21:18 ` Linus Torvalds
2008-11-17 21:25 ` Pekka Enberg
2008-11-18 0:54 ` Steven Rostedt
2008-11-18 1:05 ` Paul Mackerras
2008-11-18 1:41 ` Steven Rostedt
2008-11-18 2:01 ` Steven Rostedt
2008-11-17 22:16 ` Paul Mackerras
2008-11-17 23:30 ` Steven Rostedt
2008-11-17 23:04 ` Benjamin Herrenschmidt
2008-11-18 2:29 ` Steven Rostedt
2008-11-18 2:36 ` Paul Mackerras
2008-11-18 5:40 ` David Miller
2008-11-17 21:08 ` Andrew Morton
2008-11-17 21:23 ` Linus Torvalds
2008-11-17 21:31 ` Andrew Morton
2008-11-17 21:42 ` Linus Torvalds
2008-11-17 23:17 ` Benjamin Herrenschmidt
2008-11-17 21:09 ` Linus Torvalds
2008-11-17 22:53 ` Paul Mackerras
2008-11-18 10:07 ` Nick Piggin
2008-11-17 23:13 ` Benjamin Herrenschmidt
2008-11-17 23:22 ` Josh Boyer
2008-11-17 23:28 ` Linus Torvalds
2008-11-18 0:11 ` Paul Mackerras
2008-11-18 2:08 ` Linus Torvalds
2008-11-18 10:24 ` Nick Piggin
2008-11-18 11:44 ` Paul Mackerras
2008-11-18 16:02 ` Linus Torvalds
2008-11-18 7:25 ` Benjamin Herrenschmidt
2008-11-17 23:03 ` Benjamin Herrenschmidt
2008-11-18 9:53 ` Christoph Hellwig
2008-11-18 10:37 ` Ingo Molnar
2008-11-17 23:30 ` Benjamin Herrenschmidt
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=alpine.DEB.1.10.0811171557370.26123@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).