From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: linux-kernel@vger.kernel.org
Subject: top stack users for 2.5.71
Date: Sun, 15 Jun 2003 23:24:43 +0200 [thread overview]
Message-ID: <20030615212443.GA1181@wohnheim.fh-wedel.de> (raw)
44 functions for 2.5.67.
45 functions for 2.5.68
41 functions for 2.5.69
36 functions for 2.5.70
32 functions for 2.5.71
Five less, one more. The newcomer this time is in
drivers/usb/storage/isd200.c:
0xc0b9c9a0 isd200_action: sub $0x444,%esp
This is curious, since no obvious change causing this is in the 2.5.71
patch.
The two big consumers on the stack are these two, that use a little
over 256k and a little over 512k respectively.
struct scsi_cmnd srb;
struct scsi_device srb_dev;
This one really puzzles me, as those two variables were already present
in 2.5.67. A closer look reveals that the function isn't exactly new,
just oszillating around the 1k limit.
2.5.63:
0xc08c0be3 <isd200_action+3/1ac>: sub $0x16c,%esp
2.5.64 - 2.5.67: <1k
2.5.68:
0xc0b73c60 isd200_action: sub $0x424,%esp
2.5.69:
0xc0b4bea0 isd200_action: sub $0x414,%esp
2.5.70: <1k
2.5.71:
0xc0b9c9a0 isd200_action: sub $0x444,%esp
Quite an interesting behaviour that I don't fully understand yet.
P 0xc022f0d6 presto_get_fileid: sub $0x119c,%esp
P 0xc022d896 presto_copy_kml_tail: sub $0x1028,%esp
0xc0929258 ide_unregister: sub $0x96c,%esp
0xc0e7f4d3 snd_emu10k1_fx8010_ioctl: sub $0x830,%esp
0xc0876936 w9966_v4l_read: sub $0x828,%esp
0xc0e0fb0b snd_cmipci_ac3_copy: sub $0x7c0,%esp
0xc0e1012b snd_cmipci_ac3_silence: sub $0x7c0,%esp
0xc0105650 huft_build: sub $0x59c,%esp
0xc01073d0 huft_build: sub $0x59c,%esp
0xc02df9b6 dohash: sub $0x594,%esp
0xc0108256 inflate_dynamic: sub $0x554,%esp
0xc01064a6 inflate_dynamic: sub $0x538,%esp
0xc0223996 presto_ioctl: sub $0x508,%esp
0xc0e797a8 snd_emu10k1_add_controls: sub $0x4dc,%esp
0xc0ea1526 snd_trident_mixer: sub $0x4c0,%esp
0xc0106307 inflate_fixed: sub $0x4ac,%esp
0xc01080b7 inflate_fixed: sub $0x4ac,%esp
0xc093fff1 ide_config: sub $0x4a8,%esp
0xc05e404c parport_config: sub $0x490,%esp
0xc0c5ba23 ixj_config: sub $0x484,%esp
0xc1085e3e gss_pipe_downcall: sub $0x44c,%esp
0xc0b9c9a0 isd200_action: sub $0x444,%esp
0xc03bc848 ciGetLeafPrefixKey: sub $0x428,%esp
0xc04637c3 befs_error: sub $0x418,%esp
0xc0463833 befs_warning: sub $0x418,%esp
0xc04638a3 befs_debug: sub $0x418,%esp
0xc07d27c6 wv_hw_reset: sub $0x418,%esp
0xc16c9365 root_nfs_name: sub $0x414,%esp
0xc0c7f2d2 bt3c_config: sub $0x410,%esp
0xc0c833e2 btuart_config: sub $0x410,%esp
0xc0c7d89f dtl1_config: sub $0x408,%esp
0xc0c816b6 bluecard_config: sub $0x408,%esp
Jörn
--
If you're willing to restrict the flexibility of your approach,
you can almost always do something better.
-- John Carmack
reply other threads:[~2003-06-15 21:10 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20030615212443.GA1181@wohnheim.fh-wedel.de \
--to=joern@wohnheim.fh-wedel.de \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®