[NTOSKRNL] Bring an initial (and not perfect ;-)) implementation of read ahead to our Cc!

This halfplements CcScheduleReadAhead() which is responsible for finding the next reads
to perform given last read and previous reads. I made it very basic for now, at least
to test the whole process.
This also introduces the CcExpressWorkQueue in the lazy writer which is responsible
for dealing with read ahead items and which is dealt with before the regular queue.
In CcCopyData(), if read was fine, schedule read ahead so that it can happen in background
without the FSD to notice it! Also, update the read history so that scheduling as a
bit of data.
Implement (à la "old Cc" ;-)) CcPerformReadAhead() which is responsible for performing
the read. It's only to be called by the worker thread.

Side note on the modifications done in CcRosReleaseFileCache(). Private cache map
is tied to a handle. If it goes away, private cache map gets deleted. Read ahead
can run after the handle was closed (and thus, private cache map deleted), so
it is mandatory to always lock the master lock before accessing the structure in
read ahead or before deleting it in CcRosReleaseFileCache(). Otherwise, you'll
just break everything. You've been warned!

This commit also partly reverts f8b5d27.

CORE-14312
This commit is contained in:
Pierre Schweitzer 2018-02-09 10:06:17 +01:00
parent f4fedb936e
commit c5139563db
No known key found for this signature in database
GPG key ID: 7545556C3D585B0B
6 changed files with 314 additions and 19 deletions

View file

@ -75,10 +75,8 @@ typedef struct _PRIVATE_CACHE_MAP
LARGE_INTEGER BeyondLastByte1;
LARGE_INTEGER FileOffset2;
LARGE_INTEGER BeyondLastByte2;
ULONG SequentialReadCount;
ULONG ReadAheadLength;
LARGE_INTEGER ReadAheadOffset;
LARGE_INTEGER ReadAheadBeyondLastByte;
LARGE_INTEGER ReadAheadOffset[2];
ULONG ReadAheadLength[2];
KSPIN_LOCK ReadAheadSpinLock;
LIST_ENTRY PrivateLinks;
PVOID ReadAheadWorkItem;