https://git.reactos.org/?p=reactos.git;a=commitdiff;h=6b78ff036fb4f446f4e0a…
commit 6b78ff036fb4f446f4e0aebe5120af26d6183a77
Author: Thomas Faber <thomas.faber(a)reactos.org>
AuthorDate: Thu Mar 1 10:36:27 2018 +0100
Commit: Thomas Faber <thomas.faber(a)reactos.org>
CommitDate: Thu Mar 1 14:26:44 2018 +0100
[NTOS:KE] Don't loop indefinitely trying to figure out the CPU frequency. CORE-14419
Previously, we would keep sampling the CPU frequency until two subsequent
samples differed by at most 1 MHz. This could take several seconds, and would
unnecessarily delay boot.
Instead, if sampling is too unreliable, just give up and calculate the average
frequency from 10 samples. This is no worse than picking the frequency that
just happened to be returned twice in a row.
The fact that this method of sampling fails could indicate that there's a
problem with our performance counter implementation or timer interrupt,
but that's a separate issue...
---
ntoskrnl/ke/i386/kiinit.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/ntoskrnl/ke/i386/kiinit.c b/ntoskrnl/ke/i386/kiinit.c
index cba2c423fd..c17f4dd1f3 100644
--- a/ntoskrnl/ke/i386/kiinit.c
+++ b/ntoskrnl/ke/i386/kiinit.c
@@ -44,7 +44,7 @@ KiInitMachineDependent(VOID)
PFX_SAVE_AREA FxSaveArea;
ULONG MXCsrMask = 0xFFBF;
CPU_INFO CpuInfo;
- KI_SAMPLE_MAP Samples[4];
+ KI_SAMPLE_MAP Samples[10];
PKI_SAMPLE_MAP CurrentSample = Samples;
LARGE_IDENTITY_MAP IdentityMap;
@@ -240,11 +240,17 @@ KiInitMachineDependent(VOID)
CurrentSample++;
Sample++;
- if (Sample == sizeof(Samples) / sizeof(Samples[0]))
+ if (Sample == RTL_NUMBER_OF(Samples))
{
- /* Restart */
- CurrentSample = Samples;
- Sample = 0;
+ /* No luck. Average the samples and be done */
+ ULONG TotalMHz = 0;
+ while (Sample--)
+ {
+ TotalMHz += Samples[Sample].MHz;
+ }
+ CurrentSample[-1].MHz = TotalMHz / RTL_NUMBER_OF(Samples);
+ DPRINT1("Sampling CPU frequency failed. Using average of %lu MHz\n", CurrentSample[-1].MHz);
+ break;
}
}
https://git.reactos.org/?p=reactos.git;a=commitdiff;h=c4f58bbfd85f9c713e967…
commit c4f58bbfd85f9c713e9673114d15c61b6569e3a5
Author: Pierre Schweitzer <pierre(a)reactos.org>
AuthorDate: Wed Feb 28 20:54:53 2018 +0100
Commit: Pierre Schweitzer <pierre(a)reactos.org>
CommitDate: Wed Feb 28 20:58:36 2018 +0100
[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
---
ntoskrnl/cc/copy.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/ntoskrnl/cc/copy.c b/ntoskrnl/cc/copy.c
index 8525d9f549..c39b2148ec 100644
--- a/ntoskrnl/cc/copy.c
+++ b/ntoskrnl/cc/copy.c
@@ -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);
}