OSDev.org

Here comes some fun things to think about...

Say, one has deferred procedures in kernel, and then one goes implementing stuff such that when some driver or subsystem wants to do some work in response to an interrupts, it sets a deferred procedure in order to not block futher interrupts... and life is good, right?

Pfft. There was a problem in Vista. The problem was that if you had a 1Gb network, and enough traffic, your media playback might not work reliably.

Why?

Well, obviously Windows handles the incoming network packets the way that's easiest: ack the interrupt, schedule a DPC for the packet, then run the network stack in that DPC... which is quite fine, until you need to have some lowish-latency stuff like audio or even video running at the same time..

Ok, MS fixed that by throttling network: it'll only handle a fixed amount of packets per given interval if there's real-time media going on..

But I could think of another solution: handle the networking in a separate thread instead... now it can be given a priority lower than the media playback real-time thread. Problem solved.

So mm.. I started thinking: DPCs should only be used for stuff that's higher priority than anything that ever runs in any thread, because only when something is given to a thread, it becomes possible to tweak the priorities.

In my case so far, there are not so many things.. the above mentioned network is going to be in a separate thread I guess. I'm a little scared though about the idea of having important kernel threads like network at priority lower than stuff that's running in userspace (say a real-time audio processing thread).. so guess it's a scheduler rewrite time as well (so I can have scheduler limit the amount of CPU the real-time userspace threads are allowed to spend, before they get temporarily demoted to lower-priority).

My VFS, which is currently in the middle of a gigantic rewrite anyway, is another potential place. Would there be any real advantage of putting the VFS into a thread so as to allow other stuff to run at priority higher? It's not like VFS does a lot of things without blocking on IO anyway, but what if it doesn't block long enough? Is it ok to allow VFS to starve other stuff?

Anyway, the bottom line would probably be: anything not running in a thread (but in DPCs) can potentially starve anything running in a thread. Which is not nice.

Where do you draw the line?

First of all, I 'm not sure if I get the knack of DPC's

are they kernel threads which are given a certain function to work with?

Anyway, if they handle NETWORK stuff in a dpc in kernel land, they haven't got their design right. I wouldn't handle network stuff in a DPC for tcp/ip is a quite cumbersome thing - I think it is better to have a thread for this thing. I also think that it should be perfectly possible to have the multimedia stuff preempt the network stuff - and the other way round.

If network buffers aren't emptied quickly enough - this DOESN'T really matter! on low level, the HDLC Frames are resent if there's no ACK coming from the receiver (the ethernet network adapter IIRC - especially on a gigabit network). Don't worry, I just say. If Highest network performance is an issue whilst playing multimedia stuff, one has got his priorities the wrong way round.

As for the line to draw between: dpc <-> thread:

Take it like this: DPC's are running one after the other in kernel space. If you have loops or allocations in any dpc, this is bad. Make a task which can be preempted by other task.

DPC's shall - if I understand their nature correctly - handle the aftermath of any irq in a straight forward, linear way. If they wake up some task to do the murfle work and the cleaning up, no matter. The dpc quits as quickly as possible.

This is just my point of view, others might have a different mileage

I'm no expert, as i try to stay away from Vista News, but i am pretty sure the problem was the other way round. A new "Multimedia" class of policies in the scheduler were reducing throughput on the network.

EDIT:Spelling.

Tyler wrote:I'm no expert, as i try to stay away from Vista News, but i am pretty sure the problem was the other way round. A new "Multimedia" class of policies in the scheduler were reducing througput on the network.

Nope. If you think of it, which one is important to run in real-time?

If audio is not run in time, you'll get clicking playback, which is totally annoying. If some network packets get dropped, that's packet loss, which normal TCP/IP protocols must be designed to handle anyway.

Yeah, there was news in slashdot about how media playback lowers network performance because of the throttling hack, but the reason for the throttling was specifically that a high-speed network could otherwise starve media playback, causing buffer overflows.

I think the main complaint was that starting *any* media playback - even trivial stuff for modern computers such as an mp3 player - slowed the network to significantly below 100mbit.

distantvoices wrote:DPC's shall - if I understand their nature correctly - handle the aftermath of any irq in a straight forward, linear way. If they wake up some task to do the murfle work and the cleaning up, no matter. The dpc quits as quickly as possible.

That's exactly how I understood it as well - a DPC is similar to a soft-interrupt (or tasklet) in linux, it can't do that much work anyway because it blocks the rest of the system (anything but interrupts) while it's running (so, no blocking operations allowed). And further, AFAIK, the only thing a DPC in Windows NT should do is to enqueue a work item for a kernel thread which then executes the real work. Because of this, I never really got why DCPs are really neccessary, why not enqueue that work item from within the ISR itself? And if there is work to do at such a high priority, then it should be done from within a thread with appropriately high priority.

All IMO, of course.

cheers
Joe

JoeKayzA wrote: That's exactly how I understood it as well - a DPC is similar to a soft-interrupt (or tasklet) in linux, it can't do that much work anyway because it blocks the rest of the system (anything but interrupts) while it's running (so, no blocking operations allowed). And further, AFAIK, the only thing a DPC in Windows NT should do is to enqueue a work item for a kernel thread which then executes the real work. Because of this, I never really got why DCPs are really neccessary, why not enqueue that work item from within the ISR itself? And if there is work to do at such a high priority, then it should be done from within a thread with appropriately high priority.

All IMO, of course.

cheers
Joe

As far as I understand it, your idea of what "should" happen, is what a DPC does. A DPC is not a special scheduled object; it is simply the name of the procedure which is queued as a standard thread. It is then pre-empted like any other thread and able to do work on data retrieved by the ISR. It is also Non-blocking, and necessary in order to prevent excess blocking, by making the ISR as small as possible.