Powered by Linux
Re: can 'mac_addr' even be NULL? — Semantic Matching Tool

Re: can 'mac_addr' even be NULL?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.


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

[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux