[UDFS] Reduce mount-time NonPagedPool pressure to allow mounting on Windows Server 2003 with 2 GB RAM#283
[UDFS] Reduce mount-time NonPagedPool pressure to allow mounting on Windows Server 2003 with 2 GB RAM#283Copilot wants to merge 34 commits into
Conversation
Agent-Logs-Url: https://github.com/Zero3K20/reactos/sessions/ff223f67-8e29-494d-8ec8-faa87755450f Co-authored-by: Zero3K20 <258969903+Zero3K20@users.noreply.github.com>
Agent-Logs-Url: https://github.com/Zero3K20/reactos/sessions/ff223f67-8e29-494d-8ec8-faa87755450f Co-authored-by: Zero3K20 <258969903+Zero3K20@users.noreply.github.com>
Agent-Logs-Url: https://github.com/Zero3K20/reactos/sessions/ff223f67-8e29-494d-8ec8-faa87755450f Co-authored-by: Zero3K20 <258969903+Zero3K20@users.noreply.github.com>
Agent-Logs-Url: https://github.com/Zero3K20/reactos/sessions/ff223f67-8e29-494d-8ec8-faa87755450f Co-authored-by: Zero3K20 <258969903+Zero3K20@users.noreply.github.com>
Agent-Logs-Url: https://github.com/Zero3K20/reactos/sessions/ff223f67-8e29-494d-8ec8-faa87755450f Co-authored-by: Zero3K20 <258969903+Zero3K20@users.noreply.github.com>
Agent-Logs-Url: https://github.com/Zero3K20/reactos/sessions/ff223f67-8e29-494d-8ec8-faa87755450f Co-authored-by: Zero3K20 <258969903+Zero3K20@users.noreply.github.com>
Agent-Logs-Url: https://github.com/Zero3K20/reactos/sessions/48446a28-a62c-45a9-8125-008fb8465f5a Co-authored-by: Zero3K20 <258969903+Zero3K20@users.noreply.github.com>
|
@copilot The chunking method should be used in all the other places besides the ones that currently use it that were changed from NonpagedPool to PagedPool in the PR at assorted#19. |
Done in commit 675515a. The remaining mount-path allocations from that PR are now converted:
The I/O read buffers ( |
|
@copilot Please fix the conflicts. |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Zero3K20 <258969903+Zero3K20@users.noreply.github.com>
|
@copilot Increasing the chunk size didn’t result in the extraction of archives, etc. being the same speed as before all of the changes in this branch. Those actions are still extremely slow. Also, the driver’s file size has increased because of that change. |
Agent-Logs-Url: https://github.com/Zero3K20/reactos/sessions/1a88876f-508c-4e26-ac43-d3cd8256ebf2 Co-authored-by: Zero3K20 <258969903+Zero3K20@users.noreply.github.com>
Reverted in ff4a156 — |
…BitmapLen Three changes to eliminate the O(bits) overhead introduced by the chunked bitmap approach: 1. UDFChunkedGetBytePtr: replace ZeroChunk[UDF_CHUNK_SIZE] with a fixed 4096-byte array and a C_ASSERT that UDF_CHUNK_SIZE <= 4096. The old definition inflated the driver binary whenever UDF_CHUNK_SHIFT was raised because each translation unit embedded its own copy of the array sized to UDF_CHUNK_SIZE. The new definition is always exactly one page regardless of UDF_CHUNK_SHIFT. 2. Add UDFChunkedSetBitRange / UDFChunkedClrBitRange inline helpers and use them for UDFSetBits / UDFClrBits. The previous macros called UDFSetBit / UDFClrBit in a per-bit loop, so marking N blocks as used/free cost N chunk- pointer lookups. The new helpers handle the leading/trailing partial bytes individually and then call UDFChunkedFillMemory for the bulk middle, reducing cost to O(chunks) instead of O(bits). 3. Replace the bit-by-bit chunked path in UDFGetBitmapLen with a byte-at-a- time scan that skips unallocated (null) chunks in O(1). On a mostly-free disk almost all chunks are null; the old loop visited every bit one at a time. The new path: (a) skips an entire null chunk in one step when scanning for free bits, (b) exits immediately on a null chunk when scanning for used bits, and (c) uses a full-byte fast path inside allocated chunks. This makes UDFFindMinSuitableExtent (called for every file allocation) fast again. Agent-Logs-Url: https://github.com/Zero3K20/reactos/sessions/3ebb2bf5-c977-4e8d-8339-fe15dcc8b381 Co-authored-by: Zero3K20 <258969903+Zero3K20@users.noreply.github.com>
|
@copilot |
Remove the dead `BS = Vcb->SectorSize` assignment that was left behind after an earlier refactor; `BS` was never declared as a local variable in this function, causing a C2065 build error. `LBS` (the variable that is actually used) already receives the same value on the next line, so the dead assignment is simply dropped. Agent-Logs-Url: https://github.com/Zero3K20/reactos/sessions/9c665003-6edb-442c-889c-087c6ce3dcaa Co-authored-by: Zero3K20 <258969903+Zero3K20@users.noreply.github.com>
... Fixed in ea5bf81. |
|
@copilot |
… merge Agent-Logs-Url: https://github.com/Zero3K20/reactos/sessions/20bd7b20-0ef7-4234-a827-d560906a4d52 Co-authored-by: Zero3K20 <258969903+Zero3K20@users.noreply.github.com>
|
@copilot |
... The current crash ( Yes, Driver Verifier with special pool will find it. Here's the specific configuration:
The resulting bugcheck will include a stack showing the exact UDFS call site — which should reveal whether the FCB teardown is racing with cache teardown, or whether there is a reference-count imbalance somewhere in the FCB lifecycle code. Note: since VAT is not active on a VHD, the bitmap/allocation changes are the only significant runtime difference. If the Driver Verifier trap points into one of the new chunked-bitmap helpers (e.g.,
... The pool tag The sequence that leads to
Driver Verifier with special pool enabled: YES, this will find it. Special pool places each allocation on its own page backed by a guard page. As soon as UDFS calls The double-free is in the FCB lifecycle code (create/close/teardown), not in the bitmap changes in this PR. Without Driver Verifier output pinpointing the second-free stack, the exact location is difficult to identify from static analysis alone. |
|
@copilot |
UDFGetBitmapLenchunked path scans bit-by-bit (no null-chunk skip, no byte fast-path)UDFSetBits/UDFClrBitsmacros do per-bit chunk lookup instead of bulk fillZeroChunk[UDF_CHUNK_SIZE]in inline header function grows binary with chunk shiftUDFChunkedGetBytePtr: decoupleZeroChunksize fromUDF_CHUNK_SIZE(fixed 4096 + C_ASSERT)UDFChunkedSetBitRange/UDFChunkedClrBitRangebulk helpersUDFSetBits/UDFClrBitsmacros with the bulk helpersUDFGetBitmapLenchunked path: byte-at-a-time + null-chunk skip