[haiku-bugs] Re: [Haiku] #8466: VM caches aren't resized in some cases when cutting areas

  • From: "bonefish" <trac@xxxxxxxxxxxx>
  • Date: Fri, 13 Apr 2012 15:12:41 -0000

#8466: VM caches aren't resized in some cases when cutting areas
   Reporter:  hamish         |      Owner:  bonefish
       Type:  bug            |     Status:  assigned
   Priority:  normal         |  Milestone:  R1
  Component:  System/Kernel  |    Version:  R1/Development
 Resolution:                 |   Keywords:  kernel vm cache
 Blocked By:                 |   Blocking:
Has a Patch:  0              |   Platform:  All

Comment (by bonefish):

 Replying to [comment:2 hamish]:
 > Here's what I'm thinking of doing:
 > To handle the cut-start-of-area case, add a `VMCache::Rebase()` method
 as a counterpart to `VMCache::Resize()` which will move the virtual base
 of cache and free any pages no longer contained in the region.

 Sounds good.

 > To handle the cut-middle-of-area case, add a
 `VMCache::MovePageRange(off_t offset, off_t size, VMCache* destination,
 off_t destinationOffset)` method. Then create a new cache for the second
 area and move the pages there. I realise this is inconsistent with the
 other page moving methods because they are called on the destination
 cache, but it would be nice to iterate the page tree directly instead of
 calling `LookupPage()` repeatedly on the source cache.

 I don't see what would speak against iterating through the other cache's
 page tree.

 As an alternative solution a `status_t SplitCache(off_t offset, VMCache*&
 _newCache)` could be introduced (or with a pre-allocated cache object, if
 that makes things easier to use). Would be less flexible, but ATM I can't
 think of a use case where additional flexibility was required.

Ticket URL: <http://dev.haiku-os.org/ticket/8466#comment:3>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: