From: Takashi Iwai <tiwai@suse.de>
To: Lee Revell <rlrevell@joe-job.com>
Cc: alsa-devel <alsa-devel@lists.sourceforge.net>
Subject: Re: Stack usage
Date: Tue, 22 Mar 2005 11:22:47 +0100 [thread overview]
Message-ID: <s5hsm2o2d54.wl@alsa2.suse.de> (raw)
In-Reply-To: <1111462442.3058.4.camel@mindpipe>
At Mon, 21 Mar 2005 22:34:01 -0500,
Lee Revell wrote:
>
> Andrew Morton made an interesting post on LKML recently and mentioned
> that with 4K stacks, 512 bytes is excessive in his opinion.
>
> I ran make checkstack on my 2.6.12-rc1 tree and found some possible ALSA
> offenders:
>
> 0x0000b186 snd_emu10k1_add_controls: 588
> 0x0000b3e2 snd_emu10k1_add_controls: 588
> 0x0536 snd_seq_midisynth_register_port: 564
> 0x0933 snd_seq_midisynth_register_port: 564
> 0x00001af3 snd_iprintf: 540
> 0x00005bd3 snd_verbose_printk: 540
> 0x0743 snd_virmidi_dev_attach_seq: 464
> 0x00001c33 snd_mixer_oss_build_input: 464
> 0x0186 snd_seq_system_client_init: 436
> 0x0319 snd_seq_system_client_init: 436
> 0x00003bf6 snd_ctl_card_info: 396
> 0x00003d30 snd_ctl_card_info: 396
> 0x00003ef6 snd_pcm_oss_proc_write: 376
> 0x000042fc snd_pcm_oss_proc_write: 376
> 0x0000af26 snd_emu10k1_verify_controls: 368
> 0x0000b085 snd_emu10k1_verify_controls: 368
> 0x0000b586 snd_emu10k1_list_controls: 316
> 0x0000b616 snd_emu10k1_list_controls: 316
> 0x00001c63 snd_pcm_info_user: 308
> 0x000002e4 snd_pcm_proc_info_read: 300
> 0x00000431 snd_pcm_proc_info_read: 300
> 0x00004113 snd_ctl_elem_info_user: 296
> 0x00000e13 snd_rawmidi_info_user: 288
> 0x00004c43 snd_ctl_elem_add_user: 288
> 0x00001ab6 snd_mixer_oss_build_test: 284
> 0x00001b5a snd_mixer_oss_build_test: 284
> 0x00000f26 snd_rawmidi_info_select_user: 284
> 0x00000fb3 snd_rawmidi_info_select_user: 284
> 0x000026b6 snd_timer_user_ginfo: 268
> 0x00002882 snd_timer_user_ginfo: 268
>
> It looks like snd_emu10k1_add_controls is not too hard to fix, but maybe
> I am missing something.
It'd be easy - just use kmalloc() for the temporary
emu10k1_fx8010_control_gpr_t instance.
> Any interest in addressing this?
I'll take a look.
Most of the above will be solved easily by the use of kmalloc, I
guess. The above are all initialization or ioctls, so no
time-critical routines.
Takashi
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
next prev parent reply other threads:[~2005-03-22 10:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-22 3:34 Stack usage Lee Revell
2005-03-22 10:22 ` Takashi Iwai [this message]
2005-03-22 11:27 ` Takashi Iwai
2005-03-22 11:38 ` Ronny V. Vindenes
2005-03-22 11:43 ` Takashi Iwai
2005-03-22 15:48 ` Takashi Iwai
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=s5hsm2o2d54.wl@alsa2.suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@lists.sourceforge.net \
--cc=rlrevell@joe-job.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.