[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:
