On Wed, 2014-03-05 at 16:07 +0300, Dan Carpenter wrote:
> > FWIW, with the update, I'm seeing a lot more memory consumption (and
> > time spent processing as well) so the default parameters seem to be no
> > longer sufficient and I get things like
> >
>
> So... This update replaces state_lists (sorted lists) with strees (AVL
> trees). Lists give 0(N) for searching and inserting which sucks and
> won't scale the way I want. My testing with perf said that smatch was
> using around 30% of the time inserting and searching and my testing
> afterwards said this was true.
Oh, I have no idea, I'm just observing :)
> But I was concerned that it might use more memory... I've added some
> reference counting on strees and fixed every single leak. (We had the
> same leaks with slists).
>
> One thing I though was that I end up doing clone_stree() quite a bit.
> So I changed it so that now when you do a clone it just boosts the
> reference count and makes it copy on write. So if the clone isn't
> needed we don't use any extra memory...
>
> Ah! Ah! I had another change which reduces the number of writes. I'll
> push it now, but I'm not sure how much difference it makes.
:)
> > net/wireless/nl80211.c:2223 nl80211_set_wiphy() Function too hairy.
> > Giving up.
> >
>
> Ah... I know what this is. This is the change to how memcpy() is
> handled. This isn't the AVL changes. Maybe I should just back this
> out or turn it off by default.
>
> It ends up slowing things down a lot, especially if you use the cross
> function database. In some ways the AVL tree work is just trying to
> make the memcpy() code work.
Ok. You obviously know far better than me!
> > Increasing allowed memory consumption ten-fold seems to help ;-)
>
> What do you mean by this? How are you changing this?
+++ b/smatch_slist.c
@@ -231,7 +231,7 @@ int out_of_memory()
* It works out OK for the kernel and so it should work
* for most other projects as well.
*/
- if (sm_state_counter * sizeof(struct sm_state) >= 50000000)
+ if (sm_state_counter * sizeof(struct sm_state) >= 500000000)
seems to get rid of that "too hairy" thing.
> > I also see a lot of "ignoring unreachable code", e.g. for every BUG_ON()
> > and through a lot of inlines, but I guess that's just some new detection
> > code.
>
> Gar. I'm not sure. I haven't forgotten about the problems with the
> "ignoring unreachable code" warnings... I'll look at this.
No worries. They're easy enough to ignore, I just noticed that they
seemed to pop up much more now. Might also be kernel changes though, I
haven't really tracked this very closely with changes in both smatch and
the kernel.
johannes
--
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
