Notes on current work on Memory Management
Issues and alternatives that we want to followup:
1) Period Sync daemon threads are they necessary?
- Can we try and make this function more feed back driven and avoid period timers.... eg can we hook it up to IO feed back?
2) Are we concerned about the locking for the FCM hash and the implications
- on whether there are enforceable guarantees as to when and how often synce is called on an fcm... do we need to explore alternatives such as priorty queues to ensure that any skipped FCMs eventually get called.
3) Should pmleafs be allocating chunks directly from page allocator
- or from PMRoot. Are there implications to paging by skipping the PMRoot? Or should we be entertaining a new Paging strategy? Or maybe it does not matter. UPDATE on this: for PMLeafChunk we're going to the
PageAllocator. We would like to have it going to PMRoot, but the PMRoot can't handle different sizes right now (only handles 4k and large pages now).
4) When measuring fragmentation our first attempt is to try and approximate
- Linux notions of free block statistics. Eg. how many blocks of a give size can be allocated. Our first attempt tries to determine these facts by pushing back all free pages to the pinned page allocator in order centralize free memory and then determine fragemtation. To get this right we must try and get all free pages back to the Pinned paged allocator ... I think this might be very tricky. There are free pages in many different places including ultimately the FCMs (well mabye these pages are not "really" free but I don't think we want to ignore them from a fragmentation perspective). It is not clear that coalesing to determine fragmentation is really the way we want to go it is relatively intrusive. Two immediate options are: 1) Walk all objects that have free frames and gather stats and then
- do calcuations
- (do not be free centric) either incrementally or by brute force.
For more info on Memory Fragmentation work, see MemoryFragmentationResearchk42