it there a method to track the down the offending driver or log the time each driver is taking?
On Fri, Apr 16, 2010 at 10:19 AM, Peter G. Viscarola <pete...@osr.com>wrote: > The amount of DPC activity generated by any user-mode program is directly > proportional to the amount of device I/O it generates. Network access, disk > access, video access. If it's not causing device I/O, an application cannot > be generating or affecting DPCs in the system. > > <QUOTE> > I do not think you fully understand what a DPC actually is because a > co-processor board would not solve the DPC problem... > > As an example, an application requests data from a hardware device like a > network card or disk drive or sends data to a hardware device, like a video > card. While that hardware device is fulfilling the request, the operating > system waits momentarily for the hardware to complete it's task. A poorly > written hardware driver will keep the operating system in this "wait state" > for a long time until the task is completed and that is the reason for long > duration DPCs. > </QUOTE> > > Your description is not correct. Not at all. People are already confused > enough without having incorrect information. > > To correct your simplified example: > > As an example, an application requests data from a hardware device like a > network card or disk drive or sends data to a hardware device, like a video > card. While that request is in progress the only thing that waits is the > user application that requested the operation (and, even at that, the wait > is optional). The operating system and the driver definitely DO NOT wait. > > When the request is completed on the hardware, the hardware device > generates an interrupt to indicate that something about its state has > changed. Windows services this interrupt at VERY HIGH priority, temporarily > interrupting almost anything else happening on the system at the time, and > calls the Interrupt Service Routine of the driver responsible for the > device. In its Interrupt Service Routine, the driver examines the hardware, > determines the reason that the device interrupted, and -- if there is more > work to do -- tells the operating system to call him (the driver) back at a > LOWER priority level so he can finish attending to the device's needs > without blocking everything else on the system. This call back is a > Deferred Procedure Call (DPC). > > All requests for DPC callbacks are placed on a queue. Before returning to > execute user applications the OS will remove one DPC request at a time and > call the requesting back so the driver can complete the servicing of its > hardware device. Within its DPC, the driver for the hardware device does > whatever is necessary to service its device. This might mean moving data > from a disk controller or a network card to a user data buffer and > completing a request. But, it COULD (and most of the time WILL) mean > completing SEVERAL such requests. > > The problem occurs when there are multiple devices, each with multiple > requests, that generate interrupts within a short period of time. The DPC > queue can grow long... and the amount of time that a given driver has to > wait, from the time he requests his DPC callback from his ISR to when his > DPC callback is actually run, depends on (a) the number of DPCs in the queue > ahead of him, and (b) how much time each of those drivers spends in their > DPC callbacks. A poorly written driver will spend an unacceptably long > amount of time in its DPC, thus causing devices with DPC requests behind his > in the queue to wait an unusually long time... thus causing "excessive DPC > latency" for that waiting driver. > > To give you an idea of the timeframes we're talking about: The (currently) > suggested maximum amount of time any driver should spend in either its ISR > or DPC is 10us. In my experience, this is wishful thinking by Microsoft... > there are LOTS of drivers that spend far more than 10us in their DPC > callback routines -- There are Microsoft drivers that exceed this guideline > and I know that I've written several drivers that routinely violate it as > well. But, a well-written driver servicing a nicely designed piece of modern > hardware should be able to get close to this guideline in most > circumstances. > > Peter > K1PGV > > > _______________________________________________ > FlexRadio Systems Mailing List > FlexRadio@flex-radio.biz > http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz > Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ > Knowledge Base: http://kc.flex-radio.com/ Homepage: > http://www.flex-radio.com/ > _______________________________________________ FlexRadio Systems Mailing List FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ Knowledge Base: http://kc.flex-radio.com/ Homepage: http://www.flex-radio.com/
