From owner-svn-src-all@freebsd.org Tue Dec 12 19:22:11 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4C98E80FD6; Tue, 12 Dec 2017 19:22:11 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0287C6D51C; Tue, 12 Dec 2017 19:22:10 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vBCJLxSE018558 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Dec 2017 20:21:59 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: cem@freebsd.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id vBCJLqjU095520; Wed, 13 Dec 2017 02:21:52 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: svn commit: r326758 - in head/sys/i386: conf include To: rgrimes@freebsd.org References: <201712121701.vBCH153d087153@pdx.rh.CN85.dnsmgr.net> Cc: Don Lewis , Alexey Dokuchaev , Konstantin Belousov , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Conrad Meyer From: Eugene Grosbein Message-ID: <5A302C50.4000709@grosbein.net> Date: Wed, 13 Dec 2017 02:21:52 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <201712121701.vBCH153d087153@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, T_DATE_IN_FUTURE_96_Q autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 0.0 T_DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: * date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: ** X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 19:22:11 -0000 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 : 3312 in6_proto.o : 2232 sctp_pcb.o : 2208 xform_esp.o : 2176 ip6_output.o : 2092 ar9300_eeprom.o : 2080 kern_linker.o : 1696 md_ddf.o : 1664 cryptosoft.o : 1592 sctp_auth.o : 1420 zlib.o : 1416 ar9300_paprd.o : 1360 scsi_sa.o : 1352 scsi_da.o : 1344 nfs_nfsdport.o : 1328 vm_object.o : 1320 scsi_cd.o : 1312 scsi_enc_ses.o : 1312 fortuna.o : 1232 cam_periph.o : 1232 bt.o : 1224 zlib.o : 1192 cam_xpt.o : 1184 cam_xpt.o : 1184 ata_da.o : 1168 ata_da.o : 1160 sctp_output.o : 1160 cam_periph.o : 1152 nfs_nfsdserv.o : 1136 sctp_output.o : 1128 nfs_nfsdserv.o : 1088 rt2860.o : 1088 blkback.o : 1080 rt2860.o : 1080 pseudofs_vnops.o : 1072 cardbus_cis.o : ... First column is total stack usage of kernel function (decimal), second is module name and third contains function name it question.