Re: kern/44969: vmem_xalloc() don't search best-fit free segment in spite of VMEM_BESTFIT

[David Laight <david%l8s.co.uk@localhost>]

The following reply was made to PR kern/44969; it has been noted by GNATS.

From: David Laight <david%l8s.co.uk@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/44969: vmem_xalloc() don't search best-fit free segment in 
spite of VMEM_BESTFIT
Date: Tue, 12 Jul 2011 08:05:01 +0100

 On Tue, Jul 12, 2011 at 12:20:05AM +0000, YAMAMOTO Takashi wrote:
 > The following reply was made to PR kern/44969; it has been noted by GNATS.
 > 
 > From: yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 >      netbsd-bugs%netbsd.org@localhost
 > Subject: Re: kern/44969: vmem_xalloc() don't search best-fit free segment in
 >  spite of VMEM_BESTFIT
 > Date: Tue, 12 Jul 2011 00:17:02 +0000 (UTC)
 > 
 >  hi,
 >  
 >  >>Description:
 >  > Though you call vmem_xalloc() with VM_BESTFIT(allocation strategy),
 >  > you find that vmem_xalloc() don't search best-fit free segment. 
 >  > VMEM_BESTFIT means that using the smallest free segment that can satisfy
 >  > the allocation.But current implementation use the free segment which is
 >  > found at first.(not search best-fit free segment)
 >  
 >  it's an intended behaviour.
 >  have you seen space efficiency problems due to this?
 
 Not here, but I've had serious problems with 'first free' causing
 excessive fragmentation in the past.
 In that case changing the code to do 'best fit' completely removed
 the fragmentation issue.
 (That one may have been made worse by being a linked list, but the
 amount of dross at the front meant that I actually reduced the
 typical number of items scanned!)
 
        David
 
 -- 
 David Laight: david%l8s.co.uk@localhost