KeWaitForSingleObject sleeps on a skylake system

NTDEV
1

Hi,
I have a question related to KeWaitForSingleObject. With the new skylake system we have performance problems with our wdm driver on a Windows 7 Operating System. Our wdm driver calls KeWaitForSingleObject and on a Skylake System the thread which calls KeWaitForSingleObject sleeps for up to 60ms although the event was set.

The msdn description says
??The current state of the specified Object is examined to determine whether the wait can be satisfied immediately. If so, the necessary side effects are performed on the object. Otherwise, the current thread is put in a waiting state and a new thread is selected for execution on the current processor?.?

I know that the current thread can put to waiting state but are there any new thread scheduling mechanism related to the new skylake system. Because on a Haswell systems we have no known problems.

Thanks,
Alex

2

Have you tried running Windows Performance Analyzer to see what’s going on
around the time of the wait? Your thread might be preempted by a higher
priority thread, which would explain the 60ms (quantum is around the 60-90ms
range).

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

Hi,
I have a question related to KeWaitForSingleObject. With the new skylake
system we have performance problems with our wdm driver on a Windows 7
Operating System. Our wdm driver calls KeWaitForSingleObject and on a
Skylake System the thread which calls KeWaitForSingleObject sleeps for up to
60ms although the event was set.

The msdn description says
??The current state of the specified Object is examined to determine whether
the wait can be satisfied immediately. If so, the necessary side effects are
performed on the object. Otherwise, the current thread is put in a waiting
state and a new thread is selected for execution on the current processor?.?

I know that the current thread can put to waiting state but are there any
new thread scheduling mechanism related to the new skylake system. Because
on a Haswell systems we have no known problems.

Thanks,
Alex

3

I will test it with WPA.
In general, is it wrong to synchronize High Performance Threads with Events?

4
  1. Who sets the event? Is it a DPC?
  2. How do you measure time delta?
  3. What priority do you use for the target thread?
5

We set the event in another thread by KeSetEvent (NotificationEvent). No DPC.
The target thread priority is 30 and we measure the time delta with debug messages (before and after KeWaitforSingleObject).

6

You know that debug messages can take a lot of time?

7

We know that debug messages can take a lot of time but we see that nothing but this debug messages are enabled. I will try to log this behaviour with xperf events.

8

We have an example of injecting your own trace data into the xperf trace here:

https://www.osr.com/nt-insider/2015-issue1/happiness-xperf/

This is helpful if you can detect the delay as it narrows your search while analyzing the trace data.

-scott
OSR
@OSRDrivers