Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!husc6!encore!maxzilla.encore.com!maretz
From: maretz@maxzilla.encore.com (Andy Maretz)
Newsgroups: comp.sys.encore
Subject: Re: share_malloc under UMAX V
Message-ID: <12207@encore.Encore.COM>
Date: 10 Jul 90 20:44:02 GMT
Sender: news@Encore.COM
Reply-To: maretz@maxzilla.encore.com (Andy Maretz)
Organization: Encore Computer Corp, Marlboro, MA
Lines: 22

In article <3389@goanna.cs.rmit.oz.au> ajk@goanna.cs.rmit.oz.au (Alan Kent) writes:
>So, can anyone tell me how to calculate the number to pass to
>share_malloc_init() given that you know the number of calls to
>share_malloc() and the exact amount that needs to be allocated for
>each call?

The amount of overhead due to fragmentation will vary depending on
the above information, and also on the order in which requests are
given to share_malloc().  There isn't an easy formula to use without
building into it deep understanding about the algorithm which
share_malloc() uses, and I'm sure that no program will want to do
this.

I'd suggest adding a percentage of extra memory to the pool rather
than adding a fixed constant, which is to say, request 15% or 20%
more than the real need rather than 10K more.  In practice, I've
never seen an application that suffered more than about 20%
fragmentation with share_malloc().  The cost of overestimating the
share_malloc() pool is very low in terms of impact on real and
virtual memory, so I think you'd be OK padding pretty generously.

Andy Maretz