Re: Large stack usage in fs code (especially for PPC64)

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Mon, 2008-11-17 at 15:59 -0500, Steven Rostedt wrote:
> 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.

No, they should use their own, unless somebody change the softirq code
in ways that break us... (or unless I missed something, we based our
implementation roughtly on what x86 did back then).

Ben.

> 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