Date: Wed, 13 Dec 2017 02:21:52 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: rgrimes@freebsd.org Cc: Don Lewis <truckman@freebsd.org>, Alexey Dokuchaev <danfe@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Conrad Meyer <cem@freebsd.org> Subject: Re: svn commit: r326758 - in head/sys/i386: conf include Message-ID: <5A302C50.4000709@grosbein.net> In-Reply-To: <201712121701.vBCH153d087153@pdx.rh.CN85.dnsmgr.net> References: <201712121701.vBCH153d087153@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13.12.2017 00:01, Rodney W. Grimes wrote:
>> But many other parts of kernel think it's OK to allocate big arrays or
>> structures on stack.
>
> We should probably start looking for those, something someone who is
> offerring help but doesnt know what they might be good at, but can
> read C code. They could be utililized t simply scan through the
> code looking for this type of thing and bring it to the attention
> of a area of expertise commiter.
These can be found with simple script:
cd /usr/src
make TARGET_ARCH=i386 KERNCONF=GENERIC buildkernel
cd /usr/obj/i386.i386/home/src/sys/GENERIC
for o in *.o
do
objdump -d $o | awk -vn=$o '/sub .*,%esp/ {split ($NF,a,/[,$]/); printf "%u %s %s\n", a[2], a[2], n}'
done | sort -rn > top.sub
head -50 top.sub | while read d h o
do
objdump -d $o | fgrep -B7 "$h,%esp" | awk -vo=$o -vd=$d '/>:$/ {print d, o, $2}'
done > top2.sub
Here is what do we get in top2.sub:
4328 in6_proto.o <icmp6stat_sysctl>:
3312 in6_proto.o <ip6stat_sysctl>:
2232 sctp_pcb.o <sctp_load_addresses_from_init>:
2208 xform_esp.o <espstat_sysctl>:
2176 ip6_output.o <ip6_ctloutput>:
2092 ar9300_eeprom.o <ar9300_eeprom_restore_internal_address>:
2080 kern_linker.o <sys_kldstat>:
1696 md_ddf.o <g_raid_md_ctl_ddf>:
1664 cryptosoft.o <swcr_process>:
1592 sctp_auth.o <sctp_auth_get_cookie_params>:
1420 zlib.o <huft_build>:
1416 ar9300_paprd.o <create_pa_curve>:
1360 scsi_sa.o <saioctl>:
1352 scsi_da.o <dadone>:
1344 nfs_nfsdport.o <nfssvc_nfsd>:
1328 vm_object.o <sysctl_vm_object_list>:
1320 scsi_cd.o <cddone>:
1312 scsi_enc_ses.o <ses_devids_iter>:
1312 fortuna.o <random_fortuna_pre_read>:
1232 cam_periph.o <cam_periph_error>:
1232 bt.o <btaction>:
1224 zlib.o <inflate_trees_fixed>:
1192 cam_xpt.o <xptdoioctl>:
1184 cam_xpt.o <xptsetasyncfunc>:
1184 ata_da.o <adadump>:
1168 ata_da.o <adaasync>:
1160 sctp_output.o <sctp_med_chunk_output>:
1160 cam_periph.o <cam_periph_release_locked_buses>:
1152 nfs_nfsdserv.o <nfsrvd_lockt>:
1136 sctp_output.o <sctp_chunk_output>:
1128 nfs_nfsdserv.o <nfsrvd_lock>:
1088 rt2860.o <rt2860_raw_xmit>:
1088 blkback.o <xbb_frontend_changed>:
1080 rt2860.o <rt2860_tx>:
1080 pseudofs_vnops.o <pfs_readlink>:
1072 cardbus_cis.o <cardbus_parse_cis>:
...
First column is total stack usage of kernel function (decimal),
second is module name and third contains function name it question.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A302C50.4000709>