Re: Perforce issues in sync of ISR, DPC and Passive level code

NTDEV
1

> One very couple of generic question:

a)If an ISR is called which throws out a large amount of data from the
device and this data needs to be processed in the DPC then we need to
acquire an interrupt lock to sync the DPC and ISR. Now lets say its some
huge amount of data and I acquire the interrupt lock and the processing of
the data takes some time in DPC. Then system performance is going to go
down since DPC is taking quite some time and also ISR processing is
blocked.So what is the solution for that?

If an ISR is called, it will not conflict with a DPC unless a previous
interrupt has queued a DPC. And then, only if the ISR and DPC are working
on the same data. The best synchronization is no synchronization, that
is, create a design that does not create usage conflicts. There are
enough intrinsic synchronization problems at the ISR/DPC level, such as
usage of device registers, that you should not be introducing gratuitous
synchronization problems. The first thing I’d look at for this problem is
how to avoid any need for synchronization by making sure there is no
conflict. For example, once the ISRVfills the buffer, it can request a
DPC. The ultimate outcome of this should be that the buffer is complete
and will never, ever, be reused by the ISR. If the processing exceeds the
DPC budget, you queue up a requst for a driver thread to do the processing
(whether by using a WorkItem or your own dedicated thread), and this
thread will complete the IRP. The next interrupt will act on a different
buffer. So there is no sharing, and no need for synchronization.

b)If a process in DPC is to be sync-ed with a passive level thread lets
say a readfile request then we need to acquire a spinlock shared with the
DPC .Now if the data is huge and the passive level processing (under spin
locks) is taking time then the DPC processing will spin-wait.So system
performance goes down since DPC is blocked and it will in turn block the
scheduler from executing .So wats the solution to this?

See previous discussion. There should be no need to “sync” usage of a DPC
with a passive-level thread. Why are you sharing a buffer? What size
buffers arecwe talking about here? How much processing?
joe

The problem in above two is essentially the same: Blocking a higher
priority thread to do loads of work at lower priority thread ,when the
data structure,on which work is being performed,is shared between these
two threads

How to have a generic solution to this issue? How do drivers of high
performance/high data rate devices take care of this?

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

2

> Sorry,the title should be "Performance issues in sync of ISR,DPC and

Passive level code" not perforce

It is not a question of “performance issues”. You have not explained why
you think it is necessary to introduce gratuitous performance bottlenecks.
Your analysis of the hazards is correct, but I would look for a different
design that avoids any need for these bottlenecks. But it is hard to
suggest an alternative design without knowing any of the parameters of the
problem space.
joe

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

> Whats the src of data?Is this for some hardware device? You can use mmio

or
dma if ur device supports that…
On Dec 18, 2012 1:25 PM, wrote:
>
>> Thanks for the reply Mohan.
>>
>> But how to take care of this situation: A lock guards a data structure
>> between a high and a low priority thread (like ISR-DPC or DPC-Readfile
>> or
>> ISR-Readfile).This data structure has some huge amount of data may be in
>> MB’s.So the high priority thread ,sort of,stores the data into the data
>> structure and the low priority thread processes the data.So the lock
>> needs
>> to be acquired.Now when the low priority thread acquires this lock the
>> high
>> priority thread suffers resulting in maybe momentary system slowdown
>>
>> So how do we tackle this scenario?In case data involved is small amount
>> (lets say in bytes) then we wont notice any performance degradation else
>> there will be seriour performance hit.
>>
>>
You tackle the scenario by reconsidering the design. What you are
describing is what is known as the “priority inversion problem”, when a
lower-priority thread blocks a higher-priority thread. But without
knowing the nature of the device, the data rates, the transfer size, etc.
it is impossible tosuggest a solution.
joe
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer