2008-03-09 14:11:42 +00:00
|
|
|
/*
|
2005-01-26 13:58:37 +00:00
|
|
|
* COPYRIGHT: See COPYING in the top directory
|
2005-05-09 01:38:29 +00:00
|
|
|
* PROJECT: ReactOS kernel
|
2005-01-26 13:58:37 +00:00
|
|
|
* FILE: ntoskrnl/mm/rmap.c
|
|
|
|
* PURPOSE: Kernel memory managment functions
|
2005-05-09 01:38:29 +00:00
|
|
|
*
|
2005-01-26 13:58:37 +00:00
|
|
|
* PROGRAMMERS: David Welch (welch@cwcom.net)
|
2001-12-31 01:53:46 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
/* INCLUDES *****************************************************************/
|
|
|
|
|
2004-08-15 16:39:12 +00:00
|
|
|
#include <ntoskrnl.h>
|
2010-11-02 14:38:52 +00:00
|
|
|
#ifdef NEWCC
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
#include "../cache/section/newmm.h"
|
2010-11-02 14:38:52 +00:00
|
|
|
#endif
|
2001-12-31 01:53:46 +00:00
|
|
|
#define NDEBUG
|
2008-08-30 16:31:06 +00:00
|
|
|
#include <debug.h>
|
2001-12-31 01:53:46 +00:00
|
|
|
|
2005-11-28 23:25:31 +00:00
|
|
|
#if defined (ALLOC_PRAGMA)
|
|
|
|
#pragma alloc_text(INIT, MmInitializeRmapList)
|
|
|
|
#endif
|
|
|
|
|
2001-12-31 01:53:46 +00:00
|
|
|
/* TYPES ********************************************************************/
|
|
|
|
|
|
|
|
/* GLOBALS ******************************************************************/
|
|
|
|
|
2003-01-11 15:28:18 +00:00
|
|
|
static NPAGED_LOOKASIDE_LIST RmapLookasideList;
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
FAST_MUTEX RmapListLock;
|
2001-12-31 01:53:46 +00:00
|
|
|
|
|
|
|
/* FUNCTIONS ****************************************************************/
|
|
|
|
|
2005-09-14 01:05:50 +00:00
|
|
|
VOID
|
|
|
|
INIT_FUNCTION
|
|
|
|
NTAPI
|
2001-12-31 01:53:46 +00:00
|
|
|
MmInitializeRmapList(VOID)
|
|
|
|
{
|
2004-04-10 22:36:07 +00:00
|
|
|
ExInitializeFastMutex(&RmapListLock);
|
|
|
|
ExInitializeNPagedLookasideList (&RmapLookasideList,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
0,
|
|
|
|
sizeof(MM_RMAP_ENTRY),
|
|
|
|
TAG_RMAP,
|
|
|
|
50);
|
2001-12-31 01:53:46 +00:00
|
|
|
}
|
|
|
|
|
2002-08-14 20:58:39 +00:00
|
|
|
NTSTATUS
|
2005-09-14 01:05:50 +00:00
|
|
|
NTAPI
|
2010-07-15 22:50:12 +00:00
|
|
|
MmPageOutPhysicalAddress(PFN_NUMBER Page)
|
2002-08-14 20:58:39 +00:00
|
|
|
{
|
2004-04-10 22:36:07 +00:00
|
|
|
PMM_RMAP_ENTRY entry;
|
|
|
|
PMEMORY_AREA MemoryArea;
|
2009-04-27 10:12:57 +00:00
|
|
|
PMMSUPPORT AddressSpace;
|
2004-04-10 22:36:07 +00:00
|
|
|
ULONG Type;
|
|
|
|
PVOID Address;
|
2006-05-18 20:32:17 +00:00
|
|
|
PEPROCESS Process;
|
2004-04-10 22:36:07 +00:00
|
|
|
PMM_PAGEOP PageOp;
|
|
|
|
ULONG Offset;
|
|
|
|
NTSTATUS Status = STATUS_SUCCESS;
|
|
|
|
|
|
|
|
ExAcquireFastMutex(&RmapListLock);
|
2004-08-01 07:24:59 +00:00
|
|
|
entry = MmGetRmapListHeadPage(Page);
|
2010-02-11 18:41:45 +00:00
|
|
|
if (entry == NULL)
|
2004-04-10 22:36:07 +00:00
|
|
|
{
|
2002-05-14 21:19:21 +00:00
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
2002-08-14 20:58:39 +00:00
|
|
|
return(STATUS_UNSUCCESSFUL);
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
2006-05-18 20:32:17 +00:00
|
|
|
Process = entry->Process;
|
2010-09-27 08:46:02 +00:00
|
|
|
|
2004-04-10 22:36:07 +00:00
|
|
|
Address = entry->Address;
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
|
2005-01-02 17:55:06 +00:00
|
|
|
if ((((ULONG_PTR)Address) & 0xFFF) != 0)
|
2004-04-10 22:36:07 +00:00
|
|
|
{
|
2008-12-07 18:05:28 +00:00
|
|
|
KeBugCheck(MEMORY_MANAGEMENT);
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
2002-08-14 20:58:39 +00:00
|
|
|
|
2005-07-06 08:20:26 +00:00
|
|
|
if (Address < MmSystemRangeStart)
|
2004-04-10 22:36:07 +00:00
|
|
|
{
|
2010-09-28 16:44:18 +00:00
|
|
|
if (!ExAcquireRundownProtection(&Process->RundownProtect))
|
|
|
|
{
|
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
|
|
|
return STATUS_PROCESS_IS_TERMINATING;
|
|
|
|
}
|
|
|
|
|
2003-05-17 13:46:05 +00:00
|
|
|
Status = ObReferenceObjectByPointer(Process, PROCESS_ALL_ACCESS, NULL, KernelMode);
|
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
|
|
|
if (!NT_SUCCESS(Status))
|
2004-04-10 22:36:07 +00:00
|
|
|
{
|
2010-09-27 08:46:02 +00:00
|
|
|
ExReleaseRundownProtection(&Process->RundownProtect);
|
2004-04-10 22:36:07 +00:00
|
|
|
return Status;
|
|
|
|
}
|
2009-04-27 10:12:57 +00:00
|
|
|
AddressSpace = &Process->Vm;
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2003-05-19 15:58:09 +00:00
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
2003-05-17 13:46:05 +00:00
|
|
|
AddressSpace = MmGetKernelAddressSpace();
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
2003-05-17 13:46:05 +00:00
|
|
|
|
2004-04-10 22:36:07 +00:00
|
|
|
MmLockAddressSpace(AddressSpace);
|
2005-01-02 19:14:52 +00:00
|
|
|
MemoryArea = MmLocateMemoryAreaByAddress(AddressSpace, Address);
|
2004-04-10 22:36:07 +00:00
|
|
|
if (MemoryArea == NULL || MemoryArea->DeleteInProgress)
|
|
|
|
{
|
2003-07-15 19:31:27 +00:00
|
|
|
MmUnlockAddressSpace(AddressSpace);
|
2005-07-06 08:20:26 +00:00
|
|
|
if (Address < MmSystemRangeStart)
|
2004-04-10 22:36:07 +00:00
|
|
|
{
|
2010-09-28 16:44:18 +00:00
|
|
|
ExReleaseRundownProtection(&Process->RundownProtect);
|
2004-04-10 22:36:07 +00:00
|
|
|
ObDereferenceObject(Process);
|
|
|
|
}
|
2003-07-15 19:31:27 +00:00
|
|
|
return(STATUS_UNSUCCESSFUL);
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
|
|
|
Type = MemoryArea->Type;
|
|
|
|
if (Type == MEMORY_AREA_SECTION_VIEW)
|
|
|
|
{
|
[HAL/NDK]
- Make Vector parameter in HalEnableSystemInterrupt, HalDisableSystemInterrupt and HalBeginSystemInterrupt an ULONG, not an UCHAR
[NDK]
- 64bit fixes for HANDLE_TABLE, KPROCESS, SECTION_IMAGE_INFORMATION, MMADDRESS_LIST, MMVAD_FLAGS, MMVAD, MMVAD_LONG, MMVAD_SHORT, MEMORY_DESCRIPTOR, MEMORY_ALLOCATION_DESCRIPTOR, LdrVerifyMappedImageMatchesChecksum
- KDPC_DATA::DpcQueueDepth is signed on amd64, unsigned on x86
[NTOSKRNL]
- Fix hundreds of MSVC and amd64 warnings
- add a pragma message to FstubFixupEfiPartition, since it looks broken
- Move portable Ke constants from <arch>/cpu.c to krnlinit.c
- Fixed a bug in amd64 KiGeneralProtectionFaultHandler
svn path=/trunk/; revision=53734
2011-09-18 13:11:45 +00:00
|
|
|
Offset = (ULONG)((ULONG_PTR)Address - (ULONG_PTR)MemoryArea->StartingAddress
|
|
|
|
+ MemoryArea->Data.SectionData.ViewOffset);
|
2002-08-14 20:58:39 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Get or create a pageop
|
|
|
|
*/
|
2005-01-26 00:03:05 +00:00
|
|
|
PageOp = MmGetPageOp(MemoryArea, NULL, 0,
|
2004-04-10 22:36:07 +00:00
|
|
|
MemoryArea->Data.SectionData.Segment,
|
|
|
|
Offset, MM_PAGEOP_PAGEOUT, TRUE);
|
2002-08-14 20:58:39 +00:00
|
|
|
if (PageOp == NULL)
|
2004-04-10 22:36:07 +00:00
|
|
|
{
|
|
|
|
MmUnlockAddressSpace(AddressSpace);
|
2005-07-06 08:20:26 +00:00
|
|
|
if (Address < MmSystemRangeStart)
|
2004-04-10 22:36:07 +00:00
|
|
|
{
|
2010-09-28 16:44:18 +00:00
|
|
|
ExReleaseRundownProtection(&Process->RundownProtect);
|
2004-04-10 22:36:07 +00:00
|
|
|
ObDereferenceObject(Process);
|
|
|
|
}
|
|
|
|
return(STATUS_UNSUCCESSFUL);
|
|
|
|
}
|
|
|
|
|
2002-08-14 20:58:39 +00:00
|
|
|
/*
|
|
|
|
* Release locks now we have a page op.
|
|
|
|
*/
|
2003-05-17 13:46:05 +00:00
|
|
|
MmUnlockAddressSpace(AddressSpace);
|
2001-12-31 01:53:46 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Do the actual page out work.
|
|
|
|
*/
|
2004-04-10 22:36:07 +00:00
|
|
|
Status = MmPageOutSectionView(AddressSpace, MemoryArea,
|
|
|
|
Address, PageOp);
|
|
|
|
}
|
2010-07-22 20:48:04 +00:00
|
|
|
else if (Type == MEMORY_AREA_VIRTUAL_MEMORY)
|
2004-04-10 22:36:07 +00:00
|
|
|
{
|
2005-07-06 08:20:26 +00:00
|
|
|
PageOp = MmGetPageOp(MemoryArea, Address < MmSystemRangeStart ? Process->UniqueProcessId : NULL,
|
2004-04-10 22:36:07 +00:00
|
|
|
Address, NULL, 0, MM_PAGEOP_PAGEOUT, TRUE);
|
2004-03-05 11:31:59 +00:00
|
|
|
if (PageOp == NULL)
|
2004-04-10 22:36:07 +00:00
|
|
|
{
|
|
|
|
MmUnlockAddressSpace(AddressSpace);
|
2005-07-06 08:20:26 +00:00
|
|
|
if (Address < MmSystemRangeStart)
|
2004-04-10 22:36:07 +00:00
|
|
|
{
|
2010-09-28 16:44:18 +00:00
|
|
|
ExReleaseRundownProtection(&Process->RundownProtect);
|
2004-04-10 22:36:07 +00:00
|
|
|
ObDereferenceObject(Process);
|
|
|
|
}
|
|
|
|
return(STATUS_UNSUCCESSFUL);
|
|
|
|
}
|
2001-12-31 01:53:46 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Release locks now we have a page op.
|
|
|
|
*/
|
2003-05-17 13:46:05 +00:00
|
|
|
MmUnlockAddressSpace(AddressSpace);
|
2001-12-31 01:53:46 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Do the actual page out work.
|
|
|
|
*/
|
2004-04-10 22:36:07 +00:00
|
|
|
Status = MmPageOutVirtualMemory(AddressSpace, MemoryArea,
|
|
|
|
Address, PageOp);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2008-12-07 18:05:28 +00:00
|
|
|
KeBugCheck(MEMORY_MANAGEMENT);
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
2010-09-27 08:46:02 +00:00
|
|
|
|
2005-07-06 08:20:26 +00:00
|
|
|
if (Address < MmSystemRangeStart)
|
2004-04-10 22:36:07 +00:00
|
|
|
{
|
2010-09-28 16:44:18 +00:00
|
|
|
ExReleaseRundownProtection(&Process->RundownProtect);
|
2003-05-17 13:46:05 +00:00
|
|
|
ObDereferenceObject(Process);
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
|
|
|
return(Status);
|
2001-12-31 01:53:46 +00:00
|
|
|
}
|
|
|
|
|
2002-08-14 20:58:39 +00:00
|
|
|
VOID
|
2005-09-14 01:05:50 +00:00
|
|
|
NTAPI
|
2010-07-15 22:50:12 +00:00
|
|
|
MmSetCleanAllRmaps(PFN_NUMBER Page)
|
2002-08-14 20:58:39 +00:00
|
|
|
{
|
2004-04-10 22:36:07 +00:00
|
|
|
PMM_RMAP_ENTRY current_entry;
|
2002-08-14 20:58:39 +00:00
|
|
|
|
2004-04-10 22:36:07 +00:00
|
|
|
ExAcquireFastMutex(&RmapListLock);
|
2004-08-01 07:24:59 +00:00
|
|
|
current_entry = MmGetRmapListHeadPage(Page);
|
2004-04-10 22:36:07 +00:00
|
|
|
if (current_entry == NULL)
|
|
|
|
{
|
2002-08-14 20:58:39 +00:00
|
|
|
DPRINT1("MmIsDirtyRmap: No rmaps.\n");
|
2008-12-07 18:05:28 +00:00
|
|
|
KeBugCheck(MEMORY_MANAGEMENT);
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
|
|
|
while (current_entry != NULL)
|
|
|
|
{
|
2010-11-02 14:38:52 +00:00
|
|
|
#ifdef NEWCC
|
2011-12-25 18:21:05 +00:00
|
|
|
if (!RMAP_IS_SEGMENT(current_entry->Address))
|
2010-11-02 14:38:52 +00:00
|
|
|
#endif
|
2011-12-25 18:21:05 +00:00
|
|
|
MmSetCleanPage(current_entry->Process, current_entry->Address);
|
|
|
|
current_entry = current_entry->Next;
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
2002-08-14 20:58:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
2005-09-14 01:05:50 +00:00
|
|
|
NTAPI
|
2010-07-15 22:50:12 +00:00
|
|
|
MmSetDirtyAllRmaps(PFN_NUMBER Page)
|
2002-08-14 20:58:39 +00:00
|
|
|
{
|
2004-04-10 22:36:07 +00:00
|
|
|
PMM_RMAP_ENTRY current_entry;
|
2002-08-14 20:58:39 +00:00
|
|
|
|
2004-04-10 22:36:07 +00:00
|
|
|
ExAcquireFastMutex(&RmapListLock);
|
2004-08-01 07:24:59 +00:00
|
|
|
current_entry = MmGetRmapListHeadPage(Page);
|
2004-04-10 22:36:07 +00:00
|
|
|
if (current_entry == NULL)
|
|
|
|
{
|
2002-08-14 20:58:39 +00:00
|
|
|
DPRINT1("MmIsDirtyRmap: No rmaps.\n");
|
2008-12-07 18:05:28 +00:00
|
|
|
KeBugCheck(MEMORY_MANAGEMENT);
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
|
|
|
while (current_entry != NULL)
|
|
|
|
{
|
2010-11-02 14:38:52 +00:00
|
|
|
#ifdef NEWCC
|
2011-12-25 18:21:05 +00:00
|
|
|
if (!RMAP_IS_SEGMENT(current_entry->Address))
|
2010-11-02 14:38:52 +00:00
|
|
|
#endif
|
2011-12-25 18:21:05 +00:00
|
|
|
MmSetDirtyPage(current_entry->Process, current_entry->Address);
|
2002-08-14 20:58:39 +00:00
|
|
|
current_entry = current_entry->Next;
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
2002-08-14 20:58:39 +00:00
|
|
|
}
|
|
|
|
|
2006-01-08 06:23:17 +00:00
|
|
|
BOOLEAN
|
2005-09-14 01:05:50 +00:00
|
|
|
NTAPI
|
2010-07-15 22:50:12 +00:00
|
|
|
MmIsDirtyPageRmap(PFN_NUMBER Page)
|
2002-08-14 20:58:39 +00:00
|
|
|
{
|
2004-04-10 22:36:07 +00:00
|
|
|
PMM_RMAP_ENTRY current_entry;
|
2002-08-14 20:58:39 +00:00
|
|
|
|
2004-04-10 22:36:07 +00:00
|
|
|
ExAcquireFastMutex(&RmapListLock);
|
2004-08-01 07:24:59 +00:00
|
|
|
current_entry = MmGetRmapListHeadPage(Page);
|
2004-04-10 22:36:07 +00:00
|
|
|
if (current_entry == NULL)
|
|
|
|
{
|
2002-08-14 20:58:39 +00:00
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
|
|
|
return(FALSE);
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
|
|
|
while (current_entry != NULL)
|
|
|
|
{
|
2011-12-25 18:21:05 +00:00
|
|
|
if (
|
2010-11-02 14:38:52 +00:00
|
|
|
#ifdef NEWCC
|
2011-12-25 18:21:05 +00:00
|
|
|
!RMAP_IS_SEGMENT(current_entry->Address) &&
|
2010-11-02 14:38:52 +00:00
|
|
|
#endif
|
2011-12-25 18:21:05 +00:00
|
|
|
MmIsDirtyPage(current_entry->Process, current_entry->Address))
|
2004-04-10 22:36:07 +00:00
|
|
|
{
|
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
|
|
|
return(TRUE);
|
|
|
|
}
|
2002-08-14 20:58:39 +00:00
|
|
|
current_entry = current_entry->Next;
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
|
|
|
return(FALSE);
|
2002-08-14 20:58:39 +00:00
|
|
|
}
|
|
|
|
|
2002-05-13 18:10:41 +00:00
|
|
|
VOID
|
2005-09-14 01:05:50 +00:00
|
|
|
NTAPI
|
2010-07-15 22:50:12 +00:00
|
|
|
MmInsertRmap(PFN_NUMBER Page, PEPROCESS Process,
|
2004-04-10 22:36:07 +00:00
|
|
|
PVOID Address)
|
2002-05-13 18:10:41 +00:00
|
|
|
{
|
2004-04-10 22:36:07 +00:00
|
|
|
PMM_RMAP_ENTRY current_entry;
|
|
|
|
PMM_RMAP_ENTRY new_entry;
|
2004-10-02 10:16:10 +00:00
|
|
|
ULONG PrevSize;
|
2010-11-02 14:38:52 +00:00
|
|
|
#ifdef NEWCC
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
if (!RMAP_IS_SEGMENT(Address))
|
2010-11-02 14:38:52 +00:00
|
|
|
#endif
|
2011-12-25 18:21:05 +00:00
|
|
|
Address = (PVOID)PAGE_ROUND_DOWN(Address);
|
2002-05-13 18:10:41 +00:00
|
|
|
|
2004-04-10 22:36:07 +00:00
|
|
|
new_entry = ExAllocateFromNPagedLookasideList(&RmapLookasideList);
|
|
|
|
if (new_entry == NULL)
|
|
|
|
{
|
2008-12-07 18:05:28 +00:00
|
|
|
KeBugCheck(MEMORY_MANAGEMENT);
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
|
|
|
new_entry->Address = Address;
|
2006-05-10 17:47:44 +00:00
|
|
|
new_entry->Process = (PEPROCESS)Process;
|
2009-06-17 12:44:05 +00:00
|
|
|
#if DBG
|
2007-03-26 20:28:13 +00:00
|
|
|
#ifdef __GNUC__
|
2005-08-16 20:36:03 +00:00
|
|
|
new_entry->Caller = __builtin_return_address(0);
|
2007-03-02 18:25:23 +00:00
|
|
|
#else
|
|
|
|
new_entry->Caller = _ReturnAddress();
|
|
|
|
#endif
|
2007-10-19 23:21:45 +00:00
|
|
|
#endif
|
2002-05-13 18:10:41 +00:00
|
|
|
|
2010-11-02 14:38:52 +00:00
|
|
|
if (
|
|
|
|
#ifdef NEWCC
|
[HAL/NDK]
- Make Vector parameter in HalEnableSystemInterrupt, HalDisableSystemInterrupt and HalBeginSystemInterrupt an ULONG, not an UCHAR
[NDK]
- 64bit fixes for HANDLE_TABLE, KPROCESS, SECTION_IMAGE_INFORMATION, MMADDRESS_LIST, MMVAD_FLAGS, MMVAD, MMVAD_LONG, MMVAD_SHORT, MEMORY_DESCRIPTOR, MEMORY_ALLOCATION_DESCRIPTOR, LdrVerifyMappedImageMatchesChecksum
- KDPC_DATA::DpcQueueDepth is signed on amd64, unsigned on x86
[NTOSKRNL]
- Fix hundreds of MSVC and amd64 warnings
- add a pragma message to FstubFixupEfiPartition, since it looks broken
- Move portable Ke constants from <arch>/cpu.c to krnlinit.c
- Fixed a bug in amd64 KiGeneralProtectionFaultHandler
svn path=/trunk/; revision=53734
2011-09-18 13:11:45 +00:00
|
|
|
!RMAP_IS_SEGMENT(Address) &&
|
2010-11-02 14:38:52 +00:00
|
|
|
#endif
|
2011-12-25 18:21:05 +00:00
|
|
|
MmGetPfnForProcess(Process, Address) != Page)
|
2004-04-10 22:36:07 +00:00
|
|
|
{
|
2002-05-14 21:19:21 +00:00
|
|
|
DPRINT1("Insert rmap (%d, 0x%.8X) 0x%.8X which doesn't match physical "
|
2004-04-10 22:36:07 +00:00
|
|
|
"address 0x%.8X\n", Process->UniqueProcessId, Address,
|
2004-08-01 07:24:59 +00:00
|
|
|
MmGetPfnForProcess(Process, Address) << PAGE_SHIFT,
|
|
|
|
Page << PAGE_SHIFT);
|
2008-12-07 18:05:28 +00:00
|
|
|
KeBugCheck(MEMORY_MANAGEMENT);
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
2001-12-31 01:53:46 +00:00
|
|
|
|
2004-04-10 22:36:07 +00:00
|
|
|
ExAcquireFastMutex(&RmapListLock);
|
2004-08-01 07:24:59 +00:00
|
|
|
current_entry = MmGetRmapListHeadPage(Page);
|
2004-04-10 22:36:07 +00:00
|
|
|
new_entry->Next = current_entry;
|
2009-06-17 12:44:05 +00:00
|
|
|
#if DBG
|
2005-08-16 20:36:03 +00:00
|
|
|
while (current_entry)
|
|
|
|
{
|
|
|
|
if (current_entry->Address == new_entry->Address && current_entry->Process == new_entry->Process)
|
|
|
|
{
|
2007-10-19 23:21:45 +00:00
|
|
|
DbgPrint("MmInsertRmap tries to add a second rmap entry for address %p\n current caller ",
|
2005-08-16 20:36:03 +00:00
|
|
|
current_entry->Address);
|
2007-03-03 04:39:25 +00:00
|
|
|
DbgPrint("%p", new_entry->Caller);
|
2005-08-16 20:36:03 +00:00
|
|
|
DbgPrint("\n previous caller ");
|
2007-03-03 04:39:25 +00:00
|
|
|
DbgPrint("%p", current_entry->Caller);
|
2005-08-16 20:36:03 +00:00
|
|
|
DbgPrint("\n");
|
2008-12-07 18:05:28 +00:00
|
|
|
KeBugCheck(MEMORY_MANAGEMENT);
|
2005-08-16 20:36:03 +00:00
|
|
|
}
|
|
|
|
current_entry = current_entry->Next;
|
|
|
|
}
|
|
|
|
#endif
|
2004-08-01 07:24:59 +00:00
|
|
|
MmSetRmapListHeadPage(Page, new_entry);
|
2004-04-10 22:36:07 +00:00
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
2010-11-02 14:38:52 +00:00
|
|
|
#ifdef NEWCC
|
[HAL/NDK]
- Make Vector parameter in HalEnableSystemInterrupt, HalDisableSystemInterrupt and HalBeginSystemInterrupt an ULONG, not an UCHAR
[NDK]
- 64bit fixes for HANDLE_TABLE, KPROCESS, SECTION_IMAGE_INFORMATION, MMADDRESS_LIST, MMVAD_FLAGS, MMVAD, MMVAD_LONG, MMVAD_SHORT, MEMORY_DESCRIPTOR, MEMORY_ALLOCATION_DESCRIPTOR, LdrVerifyMappedImageMatchesChecksum
- KDPC_DATA::DpcQueueDepth is signed on amd64, unsigned on x86
[NTOSKRNL]
- Fix hundreds of MSVC and amd64 warnings
- add a pragma message to FstubFixupEfiPartition, since it looks broken
- Move portable Ke constants from <arch>/cpu.c to krnlinit.c
- Fixed a bug in amd64 KiGeneralProtectionFaultHandler
svn path=/trunk/; revision=53734
2011-09-18 13:11:45 +00:00
|
|
|
if (!RMAP_IS_SEGMENT(Address))
|
2010-11-02 14:38:52 +00:00
|
|
|
#endif
|
2004-10-02 10:16:10 +00:00
|
|
|
{
|
2011-12-25 18:21:05 +00:00
|
|
|
if (Process == NULL)
|
|
|
|
{
|
|
|
|
Process = PsInitialSystemProcess;
|
|
|
|
}
|
|
|
|
if (Process)
|
|
|
|
{
|
|
|
|
PrevSize = InterlockedExchangeAddUL(&Process->Vm.WorkingSetSize, PAGE_SIZE);
|
|
|
|
if (PrevSize >= Process->Vm.PeakWorkingSetSize)
|
|
|
|
{
|
|
|
|
Process->Vm.PeakWorkingSetSize = PrevSize + PAGE_SIZE;
|
|
|
|
}
|
|
|
|
}
|
2004-10-02 10:16:10 +00:00
|
|
|
}
|
2001-12-31 01:53:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
2005-09-14 01:05:50 +00:00
|
|
|
NTAPI
|
2010-07-15 22:50:12 +00:00
|
|
|
MmDeleteAllRmaps(PFN_NUMBER Page, PVOID Context,
|
2006-05-18 20:32:17 +00:00
|
|
|
VOID (*DeleteMapping)(PVOID Context, PEPROCESS Process,
|
2004-04-10 22:36:07 +00:00
|
|
|
PVOID Address))
|
2001-12-31 01:53:46 +00:00
|
|
|
{
|
2004-04-10 22:36:07 +00:00
|
|
|
PMM_RMAP_ENTRY current_entry;
|
|
|
|
PMM_RMAP_ENTRY previous_entry;
|
2004-10-02 10:16:10 +00:00
|
|
|
PEPROCESS Process;
|
2001-12-31 01:53:46 +00:00
|
|
|
|
2004-04-10 22:36:07 +00:00
|
|
|
ExAcquireFastMutex(&RmapListLock);
|
2004-08-01 07:24:59 +00:00
|
|
|
current_entry = MmGetRmapListHeadPage(Page);
|
2004-04-10 22:36:07 +00:00
|
|
|
if (current_entry == NULL)
|
|
|
|
{
|
2002-01-08 00:49:02 +00:00
|
|
|
DPRINT1("MmDeleteAllRmaps: No rmaps.\n");
|
2008-12-07 18:05:28 +00:00
|
|
|
KeBugCheck(MEMORY_MANAGEMENT);
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
2004-08-01 07:24:59 +00:00
|
|
|
MmSetRmapListHeadPage(Page, NULL);
|
2005-12-06 18:39:17 +00:00
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
2004-04-10 22:36:07 +00:00
|
|
|
while (current_entry != NULL)
|
|
|
|
{
|
2001-12-31 01:53:46 +00:00
|
|
|
previous_entry = current_entry;
|
|
|
|
current_entry = current_entry->Next;
|
2010-11-02 14:38:52 +00:00
|
|
|
#ifdef NEWCC
|
2011-12-25 18:21:05 +00:00
|
|
|
if (!RMAP_IS_SEGMENT(previous_entry->Address))
|
2010-11-02 14:38:52 +00:00
|
|
|
#endif
|
2011-12-25 18:21:05 +00:00
|
|
|
{
|
|
|
|
if (DeleteMapping)
|
|
|
|
{
|
|
|
|
DeleteMapping(Context, previous_entry->Process,
|
|
|
|
previous_entry->Address);
|
|
|
|
}
|
|
|
|
Process = previous_entry->Process;
|
|
|
|
ExFreeToNPagedLookasideList(&RmapLookasideList, previous_entry);
|
|
|
|
if (Process == NULL)
|
|
|
|
{
|
|
|
|
Process = PsInitialSystemProcess;
|
|
|
|
}
|
|
|
|
if (Process)
|
|
|
|
{
|
|
|
|
(void)InterlockedExchangeAddUL(&Process->Vm.WorkingSetSize, -PAGE_SIZE);
|
|
|
|
}
|
|
|
|
}
|
2010-11-02 14:38:52 +00:00
|
|
|
#ifdef NEWCC
|
2011-12-25 18:21:05 +00:00
|
|
|
else
|
|
|
|
{
|
|
|
|
ExFreeToNPagedLookasideList(&RmapLookasideList, previous_entry);
|
|
|
|
}
|
2010-11-02 14:38:52 +00:00
|
|
|
#endif
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
2001-12-31 01:53:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
2005-09-14 01:05:50 +00:00
|
|
|
NTAPI
|
2010-07-15 22:50:12 +00:00
|
|
|
MmDeleteRmap(PFN_NUMBER Page, PEPROCESS Process,
|
2004-04-10 22:36:07 +00:00
|
|
|
PVOID Address)
|
2001-12-31 01:53:46 +00:00
|
|
|
{
|
2004-04-10 22:36:07 +00:00
|
|
|
PMM_RMAP_ENTRY current_entry, previous_entry;
|
|
|
|
|
|
|
|
ExAcquireFastMutex(&RmapListLock);
|
|
|
|
previous_entry = NULL;
|
2004-08-01 07:24:59 +00:00
|
|
|
current_entry = MmGetRmapListHeadPage(Page);
|
2010-09-27 08:46:02 +00:00
|
|
|
|
2004-04-10 22:36:07 +00:00
|
|
|
while (current_entry != NULL)
|
|
|
|
{
|
2006-05-10 17:47:44 +00:00
|
|
|
if (current_entry->Process == (PEPROCESS)Process &&
|
2004-04-10 22:36:07 +00:00
|
|
|
current_entry->Address == Address)
|
|
|
|
{
|
|
|
|
if (previous_entry == NULL)
|
|
|
|
{
|
2004-08-01 07:24:59 +00:00
|
|
|
MmSetRmapListHeadPage(Page, current_entry->Next);
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
previous_entry->Next = current_entry->Next;
|
|
|
|
}
|
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
|
|
|
ExFreeToNPagedLookasideList(&RmapLookasideList, current_entry);
|
2010-11-02 14:38:52 +00:00
|
|
|
#ifdef NEWCC
|
2011-12-25 18:21:05 +00:00
|
|
|
if (!RMAP_IS_SEGMENT(Address))
|
2010-11-02 14:38:52 +00:00
|
|
|
#endif
|
2011-12-25 18:21:05 +00:00
|
|
|
{
|
|
|
|
if (Process == NULL)
|
|
|
|
{
|
|
|
|
Process = PsInitialSystemProcess;
|
|
|
|
}
|
|
|
|
if (Process)
|
|
|
|
{
|
|
|
|
(void)InterlockedExchangeAddUL(&Process->Vm.WorkingSetSize, -PAGE_SIZE);
|
|
|
|
}
|
|
|
|
}
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
previous_entry = current_entry;
|
|
|
|
current_entry = current_entry->Next;
|
|
|
|
}
|
|
|
|
KeBugCheck(MEMORY_MANAGEMENT);
|
|
|
|
}
|
|
|
|
|
2010-11-02 14:38:52 +00:00
|
|
|
#ifdef NEWCC
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
PVOID
|
|
|
|
NTAPI
|
|
|
|
MmGetSegmentRmap(PFN_NUMBER Page, PULONG RawOffset)
|
|
|
|
{
|
|
|
|
PCACHE_SECTION_PAGE_TABLE Result = NULL;
|
|
|
|
PMM_RMAP_ENTRY current_entry, previous_entry;
|
|
|
|
|
|
|
|
ExAcquireFastMutex(&RmapListLock);
|
|
|
|
previous_entry = NULL;
|
|
|
|
current_entry = MmGetRmapListHeadPage(Page);
|
|
|
|
while (current_entry != NULL)
|
|
|
|
{
|
2011-12-25 18:21:05 +00:00
|
|
|
if (RMAP_IS_SEGMENT(current_entry->Address))
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
{
|
2011-12-25 18:21:05 +00:00
|
|
|
Result = (PCACHE_SECTION_PAGE_TABLE)current_entry->Process;
|
|
|
|
*RawOffset = (ULONG_PTR)current_entry->Address & ~RMAP_SEGMENT_MASK;
|
|
|
|
InterlockedIncrementUL(&Result->Segment->ReferenceCount);
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
2011-12-25 18:21:05 +00:00
|
|
|
return Result;
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
}
|
|
|
|
previous_entry = current_entry;
|
|
|
|
current_entry = current_entry->Next;
|
|
|
|
}
|
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
MmDeleteSectionAssociation(PFN_NUMBER Page)
|
|
|
|
{
|
|
|
|
PMM_RMAP_ENTRY current_entry, previous_entry;
|
|
|
|
|
|
|
|
ExAcquireFastMutex(&RmapListLock);
|
|
|
|
previous_entry = NULL;
|
|
|
|
current_entry = MmGetRmapListHeadPage(Page);
|
|
|
|
while (current_entry != NULL)
|
|
|
|
{
|
2011-12-25 18:21:05 +00:00
|
|
|
if (RMAP_IS_SEGMENT(current_entry->Address))
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
{
|
|
|
|
if (previous_entry == NULL)
|
2010-09-27 08:46:02 +00:00
|
|
|
{
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
MmSetRmapListHeadPage(Page, current_entry->Next);
|
2010-09-27 08:46:02 +00:00
|
|
|
}
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
else
|
2010-09-27 08:46:02 +00:00
|
|
|
{
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
previous_entry->Next = current_entry->Next;
|
2010-09-27 08:46:02 +00:00
|
|
|
}
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
|
|
|
ExFreeToNPagedLookasideList(&RmapLookasideList, current_entry);
|
2004-04-10 22:36:07 +00:00
|
|
|
return;
|
|
|
|
}
|
2002-05-14 21:19:21 +00:00
|
|
|
previous_entry = current_entry;
|
|
|
|
current_entry = current_entry->Next;
|
2004-04-10 22:36:07 +00:00
|
|
|
}
|
[CACHE]
The cache manager rewrite I started years ago has finally appeared in
ReactOS' trunk and although at this point it's not quite perfectly
integrated, it's enough to boot up the bootcd or livecd. To check out
the more mature original, check out arty-newcc-reactos, branch
arty-newcc on bitbucket.org . Amine Khaldi encouraged me quite a bit
to not give up on it, and was able to reach out and be an advocate
when i really wasn't able to. Others agree that the time has come to
begin removing the old cache manager. I expect the remaining problems
in the version going to trunk will be taken care of relatively
quickly.
The motivation for this effort lies in the particularly hairy
relationship between ReactOS' cache manager and data sections. This
code completely removes page sharing between cache manager and section
and reimagines cache manager as being a facility layered on the memory
manager, not really caring about individual pages, but simply managing
data section objects where caching might occur.
It took me about 2 years to do the first pass of this rewrite and most
of this year to fix some lingering issues, properly implement demand
paging in ReactOS (code which didn't come with this patch in a
recognizable form), and finish getting the PrivateCacheMap and
SharedCacheMap relationship correct.
Currently, the new ntoskrnl/cache directory contains an own
implementation of data file sections. After things have settled down,
we can begin to deprecate and remove the parts of ReactOS' section
implementation that depend on a close relationship with cache
manager. Eventually, I think that the extra code added to
ntoskrnl/cache/section will be removed and ReactOS' own sections will
replace the use of the special MM_CACHE_SECTION_SEGMENT in the cache
path.
Note also, that this makes all cache manager (and new section parts)
use wide file offsets. If my section code were to take over other
parts of the ReactOS memory manager, they would also benefit from
these improvements.
I invite anyone who wants to to peek at this code and fix whatever
bugs can be found.
svn path=/trunk/; revision=49423
2010-11-02 02:32:39 +00:00
|
|
|
ExReleaseFastMutex(&RmapListLock);
|
2001-12-31 01:53:46 +00:00
|
|
|
}
|
2010-11-02 14:38:52 +00:00
|
|
|
#endif
|