Re: reducing stack usage in v4l?

Randy.Dunlap (rddunlap@osdl.org)
Wed, 5 Mar 2003 07:34:37 -0800


On Wed, 5 Mar 2003 09:35:34 +0000
Russell King <rmk@arm.linux.org.uk> wrote:

| On Wed, Mar 05, 2003 at 10:15:52AM +0100, Gerd Knorr wrote:
| > But when looking at the disasm output it is obvious that it isn't true
| > (at least with gcc 3.2). On the other hand it is common practice in
| > many drivers, there must be a reason for that, no? Any chance this
| > used to work with older gcc versions?
|
| I don't believe so - I seem to remember looking at gcc 2.95 and finding
| the same annoying behaviour.

Yes, that's what I'm seeing with 2.96 as well.

| > Not sure what is the best idea to fix that. Don't like the kmalloc
| > idea that much. The individual structs are not huge, the real problem
| > is that many of them are allocated and only few are needed. Any
| > chance to tell gcc that it should allocate block-local variables at
| > the start block not at the start of the function?
|
| Not a particularly clean idea, but maybe creating a union of the
| structures and putting that on the stack? (ie, doing what GCC should
| be doing in the first place.)

That's an idea. Or make separate called functions for each ioctl and declare
the structures inside them?

--
~Randy

Here are some v4l structure sizes from gcc 2.96 on a P4:

sizeof video_audio: 40 sizeof video_buffer: 20 sizeof video_capability: 60 sizeof video_channel: 48 sizeof video_mbuf: 136 sizeof video_mmap: 16 sizeof video_picture: 14 sizeof video_tuner: 52 sizeof video_window: 32 sizeof v4l2_audio: 52 sizeof v4l2_buffer: 68 sizeof v4l2_capability: 104 sizeof v4l2_control: 8 sizeof v4l2_fmtdesc: 64 sizeof v4l2_format: 204 sizeof v4l2_framebuffer: 44 sizeof v4l2_frequency: 44 sizeof v4l2_input: 76 sizeof v4l2_queryctrl: 68 sizeof v4l2_requestbuffers: 20 sizeof v4l2_tuner: 84 - 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/