Re: pfMemory - does it combine?

New Message Reply Date view Thread view Subject view Author view

Sharon Clay (src++at++rose.asd.sgi.com)
Tue, 18 Jun 1996 02:22:35 -0700


+>---- On Jun 18, 4:20pm, Keith Babarovich wrote:
> Subject: pfMemory - does it combine?
->
->If I pfMalloc a number of blocks of memory and latter
->I free up these blocks, do they get combined back together?
->
->or in other words,
->
->Does pfMemory combine adjacent free blocks into larger
->free blocks or does it continually fragment into small and small blocks?
->
->I am having a problem with our performer application continually using
->mroe and more memory until the machine crashes. While we can't seem to
->find any place where we are loosing allocated memory I am worried that
->our database paging is fragmenting the memory into small chunks that can
->not be used and then having to allocate more.

We give the memory back to the arena, created with acreate.
As such, you can use amallopt to improve the behavior of the
allocator for your application.
To reduce fragmentation, try more a aggressive check limit so
that amalloc will try harder to find a suitable block:

        amallopt(M_MAXCHK, 1000000, pfGetSharedArena());

src.

-- 
-----{-----{---++at++   -----{----{---++at++   -----{----{---++at++   -----{----{---++at++
Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev.
src++at++sgi.com  (415) 933 - 1002  FAX: (415) 965 - 2658  MS 8U-590
-----{-----{---++at++   -----{----{---++at++   -----{----{---++at++   -----{----{---++at++

======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer.html Submissions: info-performer++at++sgi.com Admin. requests: info-performer-request++at++sgi.com


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:01 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.