mirror of
https://github.com/reactos/reactos.git
synced 2025-02-22 08:25:03 +00:00
[NTOKSRNL] Don't blindly schedule read-ahead on CcCopyRead() call.
This avoids locking Cc for too long by trying to read-ahead data which is already in cache. We now will only schedule a read ahead if next read should bring us to a new VACB (perhaps not in cache). This notably fixes Inkscape setup which was slown down by read-ahead due to continous 1 byte reads. Thanks to Thomas for his help on this issue. CORE-14395
This commit is contained in:
parent
2baafa61c6
commit
c4f58bbfd8
1 changed files with 5 additions and 2 deletions
|
@ -377,8 +377,11 @@ CcCopyData (
|
|||
/* If that was a successful sync read operation, let's handle read ahead */
|
||||
if (Operation == CcOperationRead && Length == 0 && Wait)
|
||||
{
|
||||
/* If file isn't random access, schedule next read */
|
||||
if (!BooleanFlagOn(FileObject->Flags, FO_RANDOM_ACCESS))
|
||||
/* If file isn't random access and next read may get us cross VACB boundary,
|
||||
* schedule next read
|
||||
*/
|
||||
if (!BooleanFlagOn(FileObject->Flags, FO_RANDOM_ACCESS) &&
|
||||
(CurrentOffset - 1) / VACB_MAPPING_GRANULARITY != (CurrentOffset + BytesCopied - 1) / VACB_MAPPING_GRANULARITY)
|
||||
{
|
||||
CcScheduleReadAhead(FileObject, (PLARGE_INTEGER)&FileOffset, BytesCopied);
|
||||
}
|
||||
|
|
Loading…
Reference in a new issue