lkml.org 
[lkml]   [2004]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [STACK] >3k call path in ide
Hi Jorn,

Noticed that try_to_free_pages, sync_inodes_sb and wakeup_bdflush features
in almost all of these traces and although at 284, 308 and 256 respectively
their not huge but together their neither that small (considering they
occur all in the same stack trace).

This is consumed mostly by a struct page_state which is 148 bytes big
although looking at the code get_page_state(struct page_state *ret)
only populates the first 6 fields or 24 bytes. get_full_page_state
which is hardly used updates these other fields.

Is this a candidate for splitting into 2 structs? 1 containing just the
first 6 fields needed by the majority of users: try_to_free_pages,
shrink_all_memory, kswapd, get_dirty_limits, wakeup_bdflush, sync_inodes_sb

mclark@monty:/usr/src/linux$ find . -name '*.c' | xargs grep get_page_state
./fs/proc/proc_misc.c: get_page_state(&ps);
./fs/fs-writeback.c: get_page_state(&ps);
./mm/page_alloc.c:void __get_page_state(struct page_state *ret, int nr)
./mm/page_alloc.c:void get_page_state(struct page_state *ret)
./mm/page_alloc.c: __get_page_state(ret, nr + 1);
./mm/page_alloc.c: __get_page_state(ret, sizeof(*ret) / sizeof(unsigned long));
./mm/page_alloc.c: get_page_state(&ps);
./mm/vmscan.c: get_page_state(&ps);
./mm/vmscan.c: get_page_state(&ps);
./mm/vmscan.c: get_page_state(&ps);
./mm/page-writeback.c: get_page_state(ps);
./mm/page-writeback.c: * On really big machines, get_page_state is expensive, so try to avoid calling
./mm/page-writeback.c: get_page_state(&ps);
./mm/page-writeback.c: get_page_state(&ps);
./mm/page-writeback.c: * If it is too low then SMP machines will call the (expensive) get_page_state

mclark@monty:/usr/src/linux$ find . -name '*.c' | xargs grep get_full_page_state
./drivers/parisc/led.c: get_full_page_state(&pgstat); /* get no of sectors in & out */
./arch/s390/appldata/appldata_base.c:void get_full_page_state(struct page_state *ps)
./arch/s390/appldata/appldata_base.c:EXPORT_SYMBOL_GPL(get_full_page_state);
./arch/s390/appldata/appldata_mem.c: get_full_page_state(&ps);
./mm/page_alloc.c:void get_full_page_state(struct page_state *ret)
./mm/page_alloc.c: get_full_page_state(ps);

~mc

On 06/09/04 20:29, Jörn Engel wrote:
> Bartlomiej, can you put ide_config on a diet?
>
> stackframes for call path too long (3052):
> size function
> 0 client_reg_t->event_handler
> 1168 ide_config
> 12 ide_register_hw
> 44 ide_unregister
> 12 ide_unregister_subdriver
> 0 pnpide_init
> 0 pnp_register_driver
> 0 driver_register
> 20 bus_add_driver
> 16 driver_attach
> 72 tty_register_device
> 0 class_simple_device_add
> 0 class_device_register
> 16 class_device_add
> 0 kobject_add
> 0 kobject_hotplug
> 132 call_usermodehelper
> 80 wait_for_completion
> 84 schedule
> 16 __put_task_struct
> 20 audit_free
> 36 audit_log_start
> 16 __kmalloc
> 0 __get_free_pages
> 28 __alloc_pages
> 284 try_to_free_pages
> 0 out_of_memory
> 0 mmput
> 16 exit_aio
> 0 __put_ioctx
> 16 do_munmap
> 0 split_vma
> 36 vma_adjust
> 0 fput
> 0 __fput
> 0 locks_remove_flock
> 12 panic
> 0 sys_sync
> 0 sync_inodes
> 308 sync_inodes_sb
> 0 do_writepages
> 128 mpage_writepages
> 4 write_boundary_block
> 0 ll_rw_block
> 28 submit_bh
> 0 bio_alloc
> 88 mempool_alloc
> 256 wakeup_bdflush
> 20 pdflush_operation
> 0 printk
> 0 preempt_schedule
> 84 schedule
>
> Jörn
>

--
Michael Clark, . . . . . . . . . . . . michael@metaparadigm.com
Managing Director, . . . . . . . . . http://www.metaparadigm.com
Metaparadigm Pte. Ltd. . . . . . . . . . . phone: +65 6395 6277
25F Paterson Road, . . . . . . . . . . . . mobile: +65 9645 9612
Singapore 238515 . . . . . . . . . . . . . . fax: +65 6234 4043
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.078 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site