Memory loss (NOS's, not mine)

[dlf@phx.mcd.mot.com (Dave Fritsche)]

> One thing that you don't say you have tried is to turn on the "efficent"
> memory flag.  What that does is change the order of allocation in
> malloc from round-robin to first-fit.  Although slower, It usually
> results in a tighter memory system.

Ahh!  That's what I need!  Now that you mention it, I remember reading that
Kelvin had made that selectable.  I knew the algorithm had been changed to
look from the top of the list, but I forgot that I needed to specifically
request that action.

> As far as the mbox code goes, the old code would break if more than
> one users was logged in at once because there was one standard io
> buffer for everybody.  The new one allocates one dynamically per
> user, and it is this combined with the round-robin allocation that
> eats up the core so fast.

Hmm, I see.  I never really dug too deep into the Mbox code, since we've
never really had any use for it.  Honestly, the only reason it gets
exercised at all, is probably because I'm broadcasting a Netrom ID.
I suppose the folks jumping around the nodes just try connecting to
see what it is.

> Also, have you looked at the free list, to see what has been freed
> for potential re-use, but not reused yet  (use the mem free command).

I'll do that.  Guess there's quite a few possibilities I haven't
explored yet, but that's why I asked the question.  Wasn't sure what
to try next.  I'm fairly sure that turning the "mem efficient" flag
on will help a lot.  Thanks for all your help (sure hope you get on
the air soon, we need you! :-).

73 . . . Dave Fritsche (wb8zxu)
dlf@phx.mcd.mot.com (Tempe, AZ)