Intravision/reactos
1
0
Fork 0
mirror of https://github.com/reactos/reactos.git synced 2024-07-04 11:44:33 +00:00
Code Issues Packages Projects Releases Wiki Activity
reactos/ntoskrnl/mm/ARM3/syspte.c

444 lines
12 KiB
C
Raw Normal View History

- Initialize nonpaged pool expansion system PTEs (MiInitializeSystemPtes): - Just supports expansion space for now, not system space. - Very basic initialization of the accounting structures required. - Sets up the first two system PTE clusters for the space (the first contains the linkage, the second contains the sizage). - Called from MiInitializeArmPool. svn path=/trunk/; revision=41528
2009-06-22 08:51:28 +00:00
/*
* PROJECT: ReactOS Kernel
* LICENSE: BSD - See COPYING.ARM in the top level directory
* FILE: ntoskrnl/mm/ARM3/syspte.c
* PURPOSE: ARM Memory Manager System PTE Allocator
* PROGRAMMERS: ReactOS Portable Systems Group
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
* Roel Messiant (roel.messiant@reactos.org)
- Initialize nonpaged pool expansion system PTEs (MiInitializeSystemPtes): - Just supports expansion space for now, not system space. - Very basic initialization of the accounting structures required. - Sets up the first two system PTE clusters for the space (the first contains the linkage, the second contains the sizage). - Called from MiInitializeArmPool. svn path=/trunk/; revision=41528
2009-06-22 08:51:28 +00:00
*/
/* INCLUDES *******************************************************************/
#include <ntoskrnl.h>
#define NDEBUG
#include <debug.h>
#define MODULE_INVOLVED_IN_ARM3
[CMAKE][NTOS] * Improve some inclusions (avoid ../ types). * The answer is 42. svn path=/trunk/; revision=65357
2014-11-10 16:26:55 +00:00
#include <mm/ARM3/miarm.h>
- Initialize nonpaged pool expansion system PTEs (MiInitializeSystemPtes): - Just supports expansion space for now, not system space. - Very basic initialization of the accounting structures required. - Sets up the first two system PTE clusters for the space (the first contains the linkage, the second contains the sizage). - Called from MiInitializeArmPool. svn path=/trunk/; revision=41528
2009-06-22 08:51:28 +00:00
/* GLOBALS ********************************************************************/
PMMPTE MmSystemPteBase;
PMMPTE MmSystemPtesStart[MaximumPtePoolTypes];
PMMPTE MmSystemPtesEnd[MaximumPtePoolTypes];
MMPTE MmFirstFreeSystemPte[MaximumPtePoolTypes];
ULONG MmTotalFreeSystemPtes[MaximumPtePoolTypes];
- Initialize system PTE space. svn path=/trunk/; revision=41530
2009-06-22 10:22:19 +00:00
ULONG MmTotalSystemPtes;
- Add some globals WinDbg expected to find when using !sysptes and !vm. Unused but makes the debugger happy svn path=/trunk/; revision=69173
2015-09-10 19:47:45 +00:00
ULONG MiNumberOfExtraSystemPdes;
[NTOS:MM] - Add MmSysPteIndex, MmSysPteTables and MmSysPteListBySizeCount to make WinDbg's !sysptes extension happy svn path=/trunk/; revision=72490
2016-08-28 18:03:41 +00:00
const ULONG MmSysPteIndex[5] = { 1, 2, 4, 8, 16 };
const UCHAR MmSysPteTables[] = { 0, // 1
0, // 1
1, // 2
2, 2, // 4
3, 3, 3, 3, // 8
4, 4, 4, 4, 4, 4, 4, 4 // 16
};
LONG MmSysPteListBySizeCount[5];
- Initialize nonpaged pool expansion system PTEs (MiInitializeSystemPtes): - Just supports expansion space for now, not system space. - Very basic initialization of the accounting structures required. - Sets up the first two system PTE clusters for the space (the first contains the linkage, the second contains the sizage). - Called from MiInitializeArmPool. svn path=/trunk/; revision=41528
2009-06-22 08:51:28 +00:00
/* PRIVATE FUNCTIONS **********************************************************/
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
//
// The free System Page Table Entries are stored in a bunch of clusters,
// each consisting of one or more PTEs. These PTE clusters are connected
// in a singly linked list, ordered by increasing cluster size.
//
// A cluster consisting of a single PTE is marked by having the OneEntry flag
// of its PTE set. The forward link is contained in the NextEntry field.
//
// Clusters containing multiple PTEs have the OneEntry flag of their first PTE
// reset. The NextEntry field of the first PTE contains the forward link, and
// the size of the cluster is stored in the NextEntry field of its second PTE.
//
// Reserving PTEs currently happens by walking the linked list until a cluster
// is found that contains the requested amount of PTEs or more. This cluster
// is removed from the list, and the requested amount of PTEs is taken from the
// tail of this cluster. If any PTEs remain in the cluster, the linked list is
// walked again until a second cluster is found that contains the same amount
// of PTEs or more. The first cluster is then inserted in front of the second
// one.
//
// Releasing PTEs currently happens by walking the whole linked list, recording
// the first cluster that contains the amount of PTEs to release or more. When
// a cluster is found that is adjacent to the PTEs being released, this cluster
// is removed from the list and subsequently added to the PTEs being released.
// This ensures no two clusters are adjacent, which maximizes their size.
// After the walk is complete, a new cluster is created that contains the PTEs
// being released, which is then inserted in front of the recorded cluster.
//
FORCEINLINE
[NTOS] - FORCEINLINE belongs before the return type (-Wold-style-declaration) svn path=/trunk/; revision=61098
2013-11-26 13:45:33 +00:00
ULONG
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
MI_GET_CLUSTER_SIZE(IN PMMPTE Pte)
{
//
// First check for a single PTE
//
if (Pte->u.List.OneEntry)
return 1;
//
// Then read the size from the trailing PTE
//
Pte++;
[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
return (ULONG)Pte->u.List.NextEntry;
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
}
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
PMMPTE
NTAPI
MiReserveAlignedSystemPtes(IN ULONG NumberOfPtes,
IN MMSYSTEM_PTE_POOL_TYPE SystemPtePoolType,
IN ULONG Alignment)
{
- Fix several problems with the System PTE implementation, including the lack of locks. - I also didn't fully like the idea of sticking "-1" into a 5-bit wide bitfield -- instead just stuff it as 0xFFFFF with a typecast. - This seems to be NT's MM_EMPTY_LIST that shows up in a couple of ASSERTs on the checked build. - This fixes several random crashes seen on my test boxes when mapping MDLs and using NP expansion VA. - Dedicated to Brüno. svn path=/trunk/; revision=41934
2009-07-12 13:06:41 +00:00
KIRQL OldIrql;
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
PMMPTE PreviousPte, NextPte, ReturnPte;
ULONG ClusterSize;
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
// Sanity check
//
ASSERT(Alignment <= PAGE_SIZE);
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Fix several problems with the System PTE implementation, including the lack of locks. - I also didn't fully like the idea of sticking "-1" into a 5-bit wide bitfield -- instead just stuff it as 0xFFFFF with a typecast. - This seems to be NT's MM_EMPTY_LIST that shows up in a couple of ASSERTs on the checked build. - This fixes several random crashes seen on my test boxes when mapping MDLs and using NP expansion VA. - Dedicated to Brüno. svn path=/trunk/; revision=41934
2009-07-12 13:06:41 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Acquire the System PTE lock
- Fix several problems with the System PTE implementation, including the lack of locks. - I also didn't fully like the idea of sticking "-1" into a 5-bit wide bitfield -- instead just stuff it as 0xFFFFF with a typecast. - This seems to be NT's MM_EMPTY_LIST that shows up in a couple of ASSERTs on the checked build. - This fixes several random crashes seen on my test boxes when mapping MDLs and using NP expansion VA. - Dedicated to Brüno. svn path=/trunk/; revision=41934
2009-07-12 13:06:41 +00:00
//
OldIrql = KeAcquireQueuedSpinLock(LockQueueSystemSpaceLock);
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Find the last cluster in the list that doesn't contain enough PTEs
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
PreviousPte = &MmFirstFreeSystemPte[SystemPtePoolType];
[NTOS] - Introduce two MM_EMPTY_LIST definitions - one for PTE as a whole and one for MMPTE_LIST NextEntry field only and move them to the actual architecture specific headers. - Implement special pool. This is a special (Capt. Obvious!) kernel pool which is used to catch overruns or underruns, freed memory access and perform additional validation for paged/nonpaged allocations access. svn path=/trunk/; revision=53868
2011-09-26 21:57:40 +00:00
while (PreviousPte->u.List.NextEntry != MM_EMPTY_PTE_LIST)
- Fix several problems with the System PTE implementation, including the lack of locks. - I also didn't fully like the idea of sticking "-1" into a 5-bit wide bitfield -- instead just stuff it as 0xFFFFF with a typecast. - This seems to be NT's MM_EMPTY_LIST that shows up in a couple of ASSERTs on the checked build. - This fixes several random crashes seen on my test boxes when mapping MDLs and using NP expansion VA. - Dedicated to Brüno. svn path=/trunk/; revision=41934
2009-07-12 13:06:41 +00:00
{
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Get the next cluster and its size
//
NextPte = MmSystemPteBase + PreviousPte->u.List.NextEntry;
ClusterSize = MI_GET_CLUSTER_SIZE(NextPte);
//
// Check if this cluster contains enough PTEs
//
if (NumberOfPtes <= ClusterSize)
break;
//
// On to the next cluster
//
PreviousPte = NextPte;
}
//
// Make sure we didn't reach the end of the cluster list
//
[NTOS] - Introduce two MM_EMPTY_LIST definitions - one for PTE as a whole and one for MMPTE_LIST NextEntry field only and move them to the actual architecture specific headers. - Implement special pool. This is a special (Capt. Obvious!) kernel pool which is used to catch overruns or underruns, freed memory access and perform additional validation for paged/nonpaged allocations access. svn path=/trunk/; revision=53868
2011-09-26 21:57:40 +00:00
if (PreviousPte->u.List.NextEntry == MM_EMPTY_PTE_LIST)
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
{
//
// Release the System PTE lock and return failure
- Fix several problems with the System PTE implementation, including the lack of locks. - I also didn't fully like the idea of sticking "-1" into a 5-bit wide bitfield -- instead just stuff it as 0xFFFFF with a typecast. - This seems to be NT's MM_EMPTY_LIST that shows up in a couple of ASSERTs on the checked build. - This fixes several random crashes seen on my test boxes when mapping MDLs and using NP expansion VA. - Dedicated to Brüno. svn path=/trunk/; revision=41934
2009-07-12 13:06:41 +00:00
//
KeReleaseQueuedSpinLock(LockQueueSystemSpaceLock, OldIrql);
return NULL;
}
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Unlink the cluster
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
PreviousPte->u.List.NextEntry = NextPte->u.List.NextEntry;
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Check if the reservation spans the whole cluster
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
if (ClusterSize == NumberOfPtes)
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
{
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Return the first PTE of this cluster
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
ReturnPte = NextPte;
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
//
// Zero the cluster
//
if (NextPte->u.List.OneEntry == 0)
{
NextPte->u.Long = 0;
NextPte++;
}
NextPte->u.Long = 0;
}
else
{
//
// Divide the cluster into two parts
//
ClusterSize -= NumberOfPtes;
ReturnPte = NextPte + ClusterSize;
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
//
// Set the size of the first cluster, zero the second if needed
//
if (ClusterSize == 1)
{
NextPte->u.List.OneEntry = 1;
ReturnPte->u.Long = 0;
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
}
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
else
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
{
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
NextPte++;
NextPte->u.List.NextEntry = ClusterSize;
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
}
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Step through the cluster list to find out where to insert the first
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
PreviousPte = &MmFirstFreeSystemPte[SystemPtePoolType];
[NTOS] - Introduce two MM_EMPTY_LIST definitions - one for PTE as a whole and one for MMPTE_LIST NextEntry field only and move them to the actual architecture specific headers. - Implement special pool. This is a special (Capt. Obvious!) kernel pool which is used to catch overruns or underruns, freed memory access and perform additional validation for paged/nonpaged allocations access. svn path=/trunk/; revision=53868
2011-09-26 21:57:40 +00:00
while (PreviousPte->u.List.NextEntry != MM_EMPTY_PTE_LIST)
- Fix several problems with the System PTE implementation, including the lack of locks. - I also didn't fully like the idea of sticking "-1" into a 5-bit wide bitfield -- instead just stuff it as 0xFFFFF with a typecast. - This seems to be NT's MM_EMPTY_LIST that shows up in a couple of ASSERTs on the checked build. - This fixes several random crashes seen on my test boxes when mapping MDLs and using NP expansion VA. - Dedicated to Brüno. svn path=/trunk/; revision=41934
2009-07-12 13:06:41 +00:00
{
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Get the next cluster
//
NextPte = MmSystemPteBase + PreviousPte->u.List.NextEntry;
- Fix several problems with the System PTE implementation, including the lack of locks. - I also didn't fully like the idea of sticking "-1" into a 5-bit wide bitfield -- instead just stuff it as 0xFFFFF with a typecast. - This seems to be NT's MM_EMPTY_LIST that shows up in a couple of ASSERTs on the checked build. - This fixes several random crashes seen on my test boxes when mapping MDLs and using NP expansion VA. - Dedicated to Brüno. svn path=/trunk/; revision=41934
2009-07-12 13:06:41 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Check if the cluster to insert is smaller or of equal size
//
if (ClusterSize <= MI_GET_CLUSTER_SIZE(NextPte))
break;
//
// On to the next cluster
//
PreviousPte = NextPte;
- Fix several problems with the System PTE implementation, including the lack of locks. - I also didn't fully like the idea of sticking "-1" into a 5-bit wide bitfield -- instead just stuff it as 0xFFFFF with a typecast. - This seems to be NT's MM_EMPTY_LIST that shows up in a couple of ASSERTs on the checked build. - This fixes several random crashes seen on my test boxes when mapping MDLs and using NP expansion VA. - Dedicated to Brüno. svn path=/trunk/; revision=41934
2009-07-12 13:06:41 +00:00
}
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Retrieve the first cluster and link it back into the cluster list
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
NextPte = ReturnPte - ClusterSize;
NextPte->u.List.NextEntry = PreviousPte->u.List.NextEntry;
PreviousPte->u.List.NextEntry = NextPte - MmSystemPteBase;
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
}
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Decrease availability
//
MmTotalFreeSystemPtes[SystemPtePoolType] -= NumberOfPtes;
//
// Release the System PTE lock
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
- MiReserveAlignedSystemPtes: Add missing lock release, spotted by janderwald svn path=/trunk/; revision=43484
2009-10-15 18:34:21 +00:00
KeReleaseQueuedSpinLock(LockQueueSystemSpaceLock, OldIrql);
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
//
// Flush the TLB
//
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
KeFlushProcessTb();
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
//
// Return the reserved PTEs
//
return ReturnPte;
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
}
PMMPTE
NTAPI
MiReserveSystemPtes(IN ULONG NumberOfPtes,
IN MMSYSTEM_PTE_POOL_TYPE SystemPtePoolType)
{
PMMPTE PointerPte;
MiReserveSystemPtes: Don't assert that allocation succeeded, just warn if we failed. All callers of the function handle allocation failure properly. svn path=/trunk/; revision=43334
2009-10-07 20:14:01 +00:00
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
//
// Use the extended function
//
PointerPte = MiReserveAlignedSystemPtes(NumberOfPtes, SystemPtePoolType, 0);
MiReserveSystemPtes: Don't assert that allocation succeeded, just warn if we failed. All callers of the function handle allocation failure properly. svn path=/trunk/; revision=43334
2009-10-07 20:14:01 +00:00
//
// Return the PTE Pointer
//
- Move ARM Pool to 0xB0000000 to avoid clashing with existing ReactOS address space components (shouldn't happen if things work right, but better safe than sorry). - Implement System PTE allocator (MiReserveAlignedSystemPtes and MiReserveSystemPtes). Very simple yet functional, no optimizes for now. - Allocate 32 zeoring PTEs from the System PTE pool. - Not used yet, only the allocation is made to test the current framework. - Tested on VirtualBox, QEMU and VMWare with RAM sizes from 128MB to 1536MB with no problems. svn path=/trunk/; revision=41575
2009-06-23 07:49:39 +00:00
return PointerPte;
}
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
VOID
NTAPI
MiReleaseSystemPtes(IN PMMPTE StartingPte,
IN ULONG NumberOfPtes,
IN MMSYSTEM_PTE_POOL_TYPE SystemPtePoolType)
{
- Fix several problems with the System PTE implementation, including the lack of locks. - I also didn't fully like the idea of sticking "-1" into a 5-bit wide bitfield -- instead just stuff it as 0xFFFFF with a typecast. - This seems to be NT's MM_EMPTY_LIST that shows up in a couple of ASSERTs on the checked build. - This fixes several random crashes seen on my test boxes when mapping MDLs and using NP expansion VA. - Dedicated to Brüno. svn path=/trunk/; revision=41934
2009-07-12 13:06:41 +00:00
KIRQL OldIrql;
[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
ULONG ClusterSize;
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
PMMPTE PreviousPte, NextPte, InsertPte;
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
- Fix several problems with the System PTE implementation, including the lack of locks. - I also didn't fully like the idea of sticking "-1" into a 5-bit wide bitfield -- instead just stuff it as 0xFFFFF with a typecast. - This seems to be NT's MM_EMPTY_LIST that shows up in a couple of ASSERTs on the checked build. - This fixes several random crashes seen on my test boxes when mapping MDLs and using NP expansion VA. - Dedicated to Brüno. svn path=/trunk/; revision=41934
2009-07-12 13:06:41 +00:00
// Check to make sure the PTE address is within bounds
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
ASSERT(NumberOfPtes != 0);
ASSERT(StartingPte >= MmSystemPtesStart[SystemPtePoolType]);
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
ASSERT(StartingPte + NumberOfPtes - 1 <= MmSystemPtesEnd[SystemPtePoolType]);
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
- Fix several problems with the System PTE implementation, including the lack of locks. - I also didn't fully like the idea of sticking "-1" into a 5-bit wide bitfield -- instead just stuff it as 0xFFFFF with a typecast. - This seems to be NT's MM_EMPTY_LIST that shows up in a couple of ASSERTs on the checked build. - This fixes several random crashes seen on my test boxes when mapping MDLs and using NP expansion VA. - Dedicated to Brüno. svn path=/trunk/; revision=41934
2009-07-12 13:06:41 +00:00
// Zero PTEs
//
RtlZeroMemory(StartingPte, NumberOfPtes * sizeof(MMPTE));
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Fix several problems with the System PTE implementation, including the lack of locks. - I also didn't fully like the idea of sticking "-1" into a 5-bit wide bitfield -- instead just stuff it as 0xFFFFF with a typecast. - This seems to be NT's MM_EMPTY_LIST that shows up in a couple of ASSERTs on the checked build. - This fixes several random crashes seen on my test boxes when mapping MDLs and using NP expansion VA. - Dedicated to Brüno. svn path=/trunk/; revision=41934
2009-07-12 13:06:41 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Acquire the System PTE lock
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
- Fix several problems with the System PTE implementation, including the lack of locks. - I also didn't fully like the idea of sticking "-1" into a 5-bit wide bitfield -- instead just stuff it as 0xFFFFF with a typecast. - This seems to be NT's MM_EMPTY_LIST that shows up in a couple of ASSERTs on the checked build. - This fixes several random crashes seen on my test boxes when mapping MDLs and using NP expansion VA. - Dedicated to Brüno. svn path=/trunk/; revision=41934
2009-07-12 13:06:41 +00:00
OldIrql = KeAcquireQueuedSpinLock(LockQueueSystemSpaceLock);
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
// Increase availability
//
MmTotalFreeSystemPtes[SystemPtePoolType] += NumberOfPtes;
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Step through the cluster list to find where to insert the PTEs
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
PreviousPte = &MmFirstFreeSystemPte[SystemPtePoolType];
InsertPte = NULL;
[NTOS] - Introduce two MM_EMPTY_LIST definitions - one for PTE as a whole and one for MMPTE_LIST NextEntry field only and move them to the actual architecture specific headers. - Implement special pool. This is a special (Capt. Obvious!) kernel pool which is used to catch overruns or underruns, freed memory access and perform additional validation for paged/nonpaged allocations access. svn path=/trunk/; revision=53868
2011-09-26 21:57:40 +00:00
while (PreviousPte->u.List.NextEntry != MM_EMPTY_PTE_LIST)
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
{
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Get the next cluster and its size
//
NextPte = MmSystemPteBase + PreviousPte->u.List.NextEntry;
ClusterSize = MI_GET_CLUSTER_SIZE(NextPte);
//
// Check if this cluster is adjacent to the PTEs being released
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
if ((NextPte + ClusterSize == StartingPte) ||
(StartingPte + NumberOfPtes == NextPte))
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
{
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Add the PTEs in the cluster to the PTEs being released
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
NumberOfPtes += ClusterSize;
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
if (NextPte < StartingPte)
StartingPte = NextPte;
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Unlink this cluster and zero it
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
PreviousPte->u.List.NextEntry = NextPte->u.List.NextEntry;
if (NextPte->u.List.OneEntry == 0)
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
{
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
NextPte->u.Long = 0;
NextPte++;
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
}
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
NextPte->u.Long = 0;
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Invalidate the previously found insertion location, if any
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
InsertPte = NULL;
}
else
{
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// Check if the insertion location is right before this cluster
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
if ((InsertPte == NULL) && (NumberOfPtes <= ClusterSize))
InsertPte = PreviousPte;
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
// On to the next cluster
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
//
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
PreviousPte = NextPte;
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
}
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
}
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
//
// If no insertion location was found, use the tail of the list
//
if (InsertPte == NULL)
InsertPte = PreviousPte;
//
// Create a new cluster using the PTEs being released
//
if (NumberOfPtes != 1)
{
StartingPte->u.List.OneEntry = 0;
NextPte = StartingPte + 1;
NextPte->u.List.NextEntry = NumberOfPtes;
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
}
[NTOS] Complete rewrite reserving and releasing of System PTEs. The previous algorithm, in a nutshell, worked as follows: - PTE clusters are in a singly linked list, ordered by their base address. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping). - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. Problems with the previous algorithm: - While the idea is that all PTEs in clusters are zeroed, which requesters rely on, cluster bookkeeping isn't zeroed on merges. The side effect of this was that PTEs that weren't really zeroed were randomly delivered to requesters. - 99% of the time, allocations are serviced using the first cluster in the list, which is virtually always the first suitable cluster. This is so because the ordering is based on the base address of the clusters, and allocations are serviced using the cluster tail. Because the first cluster starts out as the whole pool, and the pool is quite sizable, it can deal with virtually allocations.. for a while. - A corollary of the previous point is *massive fragmentation* because: as long as an allocation isn't released back into the pool, the space of previous allocations that have been released isn't reused because the first cluster can't suck them up, and enough allocations remain in use. - The combined effect of the previous two points: a first cluster that effectively shrinks mostly, with small clusters forming behind it. Once the first cluster has shrunk far enough (which of course takes a long time), 90% of the space may still be free, scattered in mostly small clusters. This would make decent sized allocations fail because of the heavy fragmentation. - An implementation detail that caused the head of the list to be treated as a genuine cluster when the first cluster in the list was too small. The algorithm (as explained above) made this case quite unlikely until your system has been running for a while, after which it could happily corrupt list heads of other pools, depending on where the list head is with respect to its own pool. Empirically obtained data revealed that after just *booting to the desktop*, the pool for System Pte Space entries contained roughly 70 (unusable) clusters, blocking 15 to 20% of the pool. These figures increased to roughly 100 clusters and 30 to 35% after opening a foxy browser and using it to visit a mathematically inspired search engine. The same data also showed that over 95% of allocations requested just a single PTE, and a noticable allocation spike also occured in the range of 65-128 PTEs. It should be clear optimizing for small allocations is a good idea, and preferably encourage reuse the same PTEs for such allocations. And the new algorithm was born: - PTE clusters are in a singly linked list, ordered by increasing cluster size. - All PTEs in the clusters are zeroed (except for cluster list bookkeeping) .. really this time! - Upon reservation: Walk the list to get the first cluster that's large enough, cut the requested amount of PTEs off its tail and return them. - Upon release: Create a new cluster using the PTEs to release, and merge it together with possible adjacent clusters. - Both in the reservation and release actions, insertions into the list preserve the increasing cluster size order. Empirically obtained data now revealed that after just booting to the desktop, the pool for System Pte Space entries contained exactly 2 clusters. This increased to 10 clusters after some minor internet browsing and watching a 5 minute video using a media player. svn path=/trunk/; revision=50347
2011-01-09 20:52:22 +00:00
else
StartingPte->u.List.OneEntry = 1;
//
// Link the new cluster into the cluster list at the insertion location
//
StartingPte->u.List.NextEntry = InsertPte->u.List.NextEntry;
InsertPte->u.List.NextEntry = StartingPte - MmSystemPteBase;
//
// Release the System PTE lock
//
KeReleaseQueuedSpinLock(LockQueueSystemSpaceLock, OldIrql);
- Implement MiReleaseSystemPtes which is the function to deallocate System PTE allocations. - We do some minor optimizations to combine chunks if possible after a free, similar to MD Block algorithms in freeldr.c. svn path=/trunk/; revision=41626
2009-06-27 02:56:58 +00:00
}
[REACTOS] Cleanup INIT and some PAGE section allocations - Change INIT_FUNCTION and INIT_SECTION to CODE_SEG("INIT") and DATA_SEG("INIT") respectively - Remove INIT_FUNCTION from function prototypes - Remove alloc_text pragma calls as they are not needed anymore
2020-10-06 19:44:01 +00:00
CODE_SEG("INIT")
- Initialize nonpaged pool expansion system PTEs (MiInitializeSystemPtes): - Just supports expansion space for now, not system space. - Very basic initialization of the accounting structures required. - Sets up the first two system PTE clusters for the space (the first contains the linkage, the second contains the sizage). - Called from MiInitializeArmPool. svn path=/trunk/; revision=41528
2009-06-22 08:51:28 +00:00
VOID
NTAPI
MiInitializeSystemPtes(IN PMMPTE StartingPte,
IN ULONG NumberOfPtes,
IN MMSYSTEM_PTE_POOL_TYPE PoolType)
{
//
// Sanity checks
//
ASSERT(NumberOfPtes >= 1);
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Initialize nonpaged pool expansion system PTEs (MiInitializeSystemPtes): - Just supports expansion space for now, not system space. - Very basic initialization of the accounting structures required. - Sets up the first two system PTE clusters for the space (the first contains the linkage, the second contains the sizage). - Called from MiInitializeArmPool. svn path=/trunk/; revision=41528
2009-06-22 08:51:28 +00:00
//
// Set the starting and ending PTE addresses for this space
//
[NTOS]: To Timo, with Love (make System PTEs work on x64). svn path=/trunk/; revision=48192
2010-07-22 18:55:36 +00:00
MmSystemPteBase = MI_SYSTEM_PTE_BASE;
- Initialize nonpaged pool expansion system PTEs (MiInitializeSystemPtes): - Just supports expansion space for now, not system space. - Very basic initialization of the accounting structures required. - Sets up the first two system PTE clusters for the space (the first contains the linkage, the second contains the sizage). - Called from MiInitializeArmPool. svn path=/trunk/; revision=41528
2009-06-22 08:51:28 +00:00
MmSystemPtesStart[PoolType] = StartingPte;
MmSystemPtesEnd[PoolType] = StartingPte + NumberOfPtes - 1;
- Cleanup some debug-only debug prints. - Make the VA-range-printing debug prints match the same format as those in ReactOS Mm (MiDbgKernelLayout). - Add the appropriate number of spaces so that the layout appears continuous, even though it's coming from two source files. - This makes it easy to see the VA mappings at boot (but not all of them). svn path=/trunk/; revision=41709
2009-06-30 10:38:51 +00:00
DPRINT("System PTE space for %d starting at: %p and ending at: %p\n",
PoolType, MmSystemPtesStart[PoolType], MmSystemPtesEnd[PoolType]);
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Initialize nonpaged pool expansion system PTEs (MiInitializeSystemPtes): - Just supports expansion space for now, not system space. - Very basic initialization of the accounting structures required. - Sets up the first two system PTE clusters for the space (the first contains the linkage, the second contains the sizage). - Called from MiInitializeArmPool. svn path=/trunk/; revision=41528
2009-06-22 08:51:28 +00:00
//
// Clear all the PTEs to start with
//
RtlZeroMemory(StartingPte, NumberOfPtes * sizeof(MMPTE));
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Initialize nonpaged pool expansion system PTEs (MiInitializeSystemPtes): - Just supports expansion space for now, not system space. - Very basic initialization of the accounting structures required. - Sets up the first two system PTE clusters for the space (the first contains the linkage, the second contains the sizage). - Called from MiInitializeArmPool. svn path=/trunk/; revision=41528
2009-06-22 08:51:28 +00:00
//
// Make the first entry free and link it
//
[NTOS] - Introduce two MM_EMPTY_LIST definitions - one for PTE as a whole and one for MMPTE_LIST NextEntry field only and move them to the actual architecture specific headers. - Implement special pool. This is a special (Capt. Obvious!) kernel pool which is used to catch overruns or underruns, freed memory access and perform additional validation for paged/nonpaged allocations access. svn path=/trunk/; revision=53868
2011-09-26 21:57:40 +00:00
StartingPte->u.List.NextEntry = MM_EMPTY_PTE_LIST;
- Initialize nonpaged pool expansion system PTEs (MiInitializeSystemPtes): - Just supports expansion space for now, not system space. - Very basic initialization of the accounting structures required. - Sets up the first two system PTE clusters for the space (the first contains the linkage, the second contains the sizage). - Called from MiInitializeArmPool. svn path=/trunk/; revision=41528
2009-06-22 08:51:28 +00:00
MmFirstFreeSystemPte[PoolType].u.Long = 0;
MmFirstFreeSystemPte[PoolType].u.List.NextEntry = StartingPte -
MmSystemPteBase;
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Initialize nonpaged pool expansion system PTEs (MiInitializeSystemPtes): - Just supports expansion space for now, not system space. - Very basic initialization of the accounting structures required. - Sets up the first two system PTE clusters for the space (the first contains the linkage, the second contains the sizage). - Called from MiInitializeArmPool. svn path=/trunk/; revision=41528
2009-06-22 08:51:28 +00:00
//
// The second entry stores the size of this PTE space
//
StartingPte++;
StartingPte->u.Long = 0;
StartingPte->u.List.NextEntry = NumberOfPtes;
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Initialize nonpaged pool expansion system PTEs (MiInitializeSystemPtes): - Just supports expansion space for now, not system space. - Very basic initialization of the accounting structures required. - Sets up the first two system PTE clusters for the space (the first contains the linkage, the second contains the sizage). - Called from MiInitializeArmPool. svn path=/trunk/; revision=41528
2009-06-22 08:51:28 +00:00
//
// We also keep a global for it
//
MmTotalFreeSystemPtes[PoolType] = NumberOfPtes;
[NTOSKRNL] Remove all #line 15 "ARM³::BLA" Reasons: - It doesn't provide any benefits, its only purpose was to "look cool" - It never looked cool, instead a character mess appeared - It makes finding the related file harder, especially when the file is named differently then the description or when multiple files have the same tag - It effectively breaks Coverity scans svn path=/trunk/; revision=50149
2010-12-26 15:23:03 +00:00
- Initialize system PTE space. svn path=/trunk/; revision=41530
2009-06-22 10:22:19 +00:00
//
// Check if this is the system PTE space
//
if (PoolType == SystemPteSpace)
{
//
// Remember how many PTEs we have
//
MmTotalSystemPtes = NumberOfPtes;
}
- Initialize nonpaged pool expansion system PTEs (MiInitializeSystemPtes): - Just supports expansion space for now, not system space. - Very basic initialization of the accounting structures required. - Sets up the first two system PTE clusters for the space (the first contains the linkage, the second contains the sizage). - Called from MiInitializeArmPool. svn path=/trunk/; revision=41528
2009-06-22 08:51:28 +00:00
}
/* EOF */
Reference in a new issue Copy permalink