| commit | 56938a0f1a535a45a267c7b54d57a279133c8c41 | |
| author | Dan Carpenter <dan.carpenter@oracle.com> | |
| Thu, 11 Jan 2018 13:20:14 +0000 (11 16:20 +0300) | ||
| committer | Dan Carpenter <dan.carpenter@oracle.com> | |
| Thu, 11 Jan 2018 13:20:14 +0000 (11 16:20 +0300) | ||
| tree | d05d7460fc3902187fcccf81d9cdf3991e334003 | treesnapshot (tar.gz zip) |
| parent | ebb9635c7c61faa780c8f80577215cade1eec03a | commitdiff |
DB: introduce a timeout handling caller info
The upper bound is that if a function is called over 200 times then we
don't use the caller_info. I ran into a situation in the kernel where a
function was called exactly 200 times and it had about 200 states per call
which meant that we loaded 40,000 into the cur_stree. It took about 6
minutes.
So now I've decide that if loading the information takes longer than 10
seconds, I'm just going to bail on that.
There are a bunch of unrelated clean up changes in this and I'm sorry for
that...
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
The upper bound is that if a function is called over 200 times then we
don't use the caller_info. I ran into a situation in the kernel where a
function was called exactly 200 times and it had about 200 states per call
which meant that we loaded 40,000 into the cur_stree. It took about 6
minutes.
So now I've decide that if loading the information takes longer than 10
seconds, I'm just going to bail on that.
There are a bunch of unrelated clean up changes in this and I'm sorry for
that...
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
| smatch_db.c | diffblobblamehistory |