| From: David Gesswein <[EMAIL PROTECTED]>
| Subject: Re: [ivtv-devel] #0.2.0-rc3g and #0.3.2e fixes
|
| > The main change is to make as many seq arrays as possible static const.
| > If they had a non-const part, I had to leave them on the stack. David
| > went to the trouble of kmallocing everything.
| >
| I had missed one of the big arrays so started moving smaller stuff.
| The non const ones were about 300 bytes so may be ok with the other
| stuff fixed. Does anybody know the proper way to figure out how much
| statck was used?
No, I don't know the proper or conventional way (if any).
But here is an approach that seems to work. I just made this up now,
so there is probably a better way. Remember, my system is an X86_64
running Fedora Core 3 with a 2.6 kernel.
1) compile the modules to assembler (.s) files
2) look at the assembly code to find the size of stack being
allocated.
To compile to assembly code, I first needed to know how the code is
supposed to be compiled. The output of "make" is very terse -- it no
longer shows you the actual commands executed.
1a: clean up any residue from previous builds
make clean
1b: do a make with verbose output to see how the files are compiled.
I need to capture the log. You could do this with script (I used
a different tool):
script
make KBUILD_VERBOSE=1
exit
1c: look at the script output ("typescript") to find the directory the
compile was done in:
make[1]: Entering directory `/lib/modules/2.6.10-1.741_FC3/build'
and the actual gcc command:
gcc -Wp,-MD,/home/hugh/tba/ivtv/ivtv-0.3.2e/driver/.cx25840-driver.o.d
-nostdinc -iwithprefix include -D__KERNEL__ -Iinclude -Wall
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os
-fomit-frame-pointer -g -mno-red-zone -mcmodel=kernel -pipe
-fno-reorder-blocks -Wno-sign-compare -funit-at-a-time
-Wdeclaration-after-statement -DMODULE -DKBUILD_BASENAME=cx25840_driver
-DKBUILD_MODNAME=cx25840 -c -o
/home/hugh/tba/ivtv/ivtv-0.3.2e/driver/.tmp_cx25840-driver.o
/home/hugh/tba/ivtv/ivtv-0.3.2e/driver/cx25840-driver.c
1d: issue a variant of that command to create assembly code (.s) file.
You need to set where the output goes -- change the -o flag's
operand.
You need to add the -S flag, replacing the -c flag, to tell it
that you want assembly code.
bash
cd /lib/modules/2.6.10-1.741_FC3/build
gcc -Wp,-MD,/home/hugh/tba/ivtv/ivtv-0.3.2e/driver/.cx25840-driver.o.d
-nostdinc -iwithprefix include -D__KERNEL__ -Iinclude -Wall
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os
-fomit-frame-pointer -g -mno-red-zone -mcmodel=kernel -pipe
-fno-reorder-blocks -Wno-sign-compare -funit-at-a-time
-Wdeclaration-after-statement -DMODULE -DKBUILD_BASENAME=cx25840_driver
-DKBUILD_MODNAME=cx25840 -S -o ~/cx25840-driver.s
/home/hugh/tba/ivtv/ivtv-0.3.2e/driver/cx25840-driver.c
exit
The assembly code should now be in wherever your -o operand
pointed.
Now you need to peer at the assembly code for function prologues that
allocate stack space. On my system, it looks as if space is allocated
by instructions like:
subq $2632, %rsp
This says: subtract a constant from the stack pointer register (stacks
grow down). Look for big constants. I can imagine that some
functions don't have a subq, but only if they are allocating a very
small amount of stack. (Or if they use run-time sized arrays, a
recent feature of C; I assume that the driver does not use this.)
Here are the top consumers of stack space in
ivtv-0.3.2e/driver/cx25840-driver.c after my changes, but not Davids.
I don't know the call graph, so I don't know if these need to be added
together.
2632 setting_sequencer
1576 cx25840_detect_client
1384 cx25840_command
456 set_default_values
[Remember that I'm on x86_64 so pointers take twice as much memory as
on i386. To accommodate this, x86_64 linux allows twice as much stack
space as i386.]
David:
My intuition is that kmalloc is to be avoided if possible. The call
is much more expensive than stack allocation. And it can fail. And
it can cause fragmentation. And you have to be careful to ensure that
the memory is freed exactly once. So it is best to limit it to
allocating big things. For some meaning of "big".
If there are two or more big things in a function, perhaps one kmalloc
can be used to allocate space for all at once.
I would guess that the top 3 of these functions should be fixed to use
less stack. Probably using kmalloc. The fourth might be acceptable
the way it is. This depends on the call graph, something that I am
ignoring.
Since all your changes were to cx25840-driver.c, perhaps I have given
you all the information you were asking for.
I think that it would be good for you to resubmit your patch, perhaps
improved. It does address an important problem.
Thanks.
-------------------------------------------------------
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
_______________________________________________
ivtv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
