On 02/12/2014 05:51 PM, Dan Carpenter wrote:
On Wed, Feb 12, 2014 at 03:57:34PM -0600, Larry Finger wrote:
Dan,
As my version of Smatch did not show some of the warnings that you
reported to me earlier, I did a git pull and ran into a regression
that causes Smatch to run very slowly, and may have an infinite
loop. I bisected the problem and got the following:
Commit Execution time
2c45218 35 sec
3ef1e73 4 min 43 sec
d94be05 Not finished after 1 hour
Those are sequential commits. All of these were run on an otherwise
unloaded system on the current code in drivers/staging/rtl8188eu/.
The command used was
time make CHECK=~/smatch/smatch C=2 drivers/staging/rtl8188eu/
As you see, make used only a single CPU. None of the files needed to
be compiled.
I will be happy to test any fixes. For the moment, I am sticking
with commit 2c45218.
On my system there are 2 files which take 6 minutes to process, so 12
minutes total if you are building on 1 CPU. Six minutes is sort of long
but it's endurable. How much RAM do you have? Perhaps you are
swapping, I can add a work around if we're running out of memory.
I have 3 GB. I reran the test with "make -j2" and got the following:
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:4403 rtw_dbg_port() Function too
hairy. Giving up.
real 135m8.081s
user 220m11.645s
sys 1m55.307s
This time I was watching top while it ran. One of the routines that finished
used ~80 min. The one that failed had used about 45 min, and it had a virtual
memory footprint of 1.5 GB.
These times are not really endurable.
Larry
--
To unsubscribe from this list: send the line "unsubscribe smatch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
