There was a VERY good article on worker threads in the NT Insider in 1998.
I use that code all the time I need to have something run at passive level
from a higher IRQL. I also always use my own worker threads.
“Peter W. Morreale” wrote in message
news:xxxxx@ntdev…
> On Fri, 2010-01-15 at 08:23 +1100, James Harper wrote:
>> >
>> > In the Linux guests, we use tasklets for this purpose, which are a
>> very
>> > lightweight async mechanism. It appears that Windows DPCs are the
>> > similar mechanism.
>> >
>>
>> Aren’t Linux tasklets more like Windows workitems? I thought the Linux
>> “bottom half” interrupt handler was more equivalent to a Windows DPC?
>> There are enough differences between the two operating systems that the
>> comparison isn’t really useful though.
>>
>
> Good question. The only documentation I can find on ‘workitems’ relate
> to userspace apps.
>
> Yes, from what I gleam, a DPC is equivalent to ‘bottom-half’ processing,
> although these days there is a push to move that to a kernel thread in
> Linux. (Certainly is true in RT Linux systems like SLERT.)
>
>
>> If you are approaching the maximum amount of work to be done in a Dpc
>> (based on how many packets you think you can process before too much
>> time elapses), queue another Dpc and exit. The system will put your Dpc
>> on the end of the Dpc queue (giving other Dpc’s a chance to run) and get
>> back to you in good time. I don’t think this is strictly permitted
>> within NDIS (queuing another Dpc), but I doubt it will be a problem if
>> you do it right.
>
>> It’s hard to tune though… how many packets is too many to process per
>> Dpc? What if the user decides that their system must process network
>> packets above all else and they don’t particularly care if Dpc
>> processing time takes more than it should? (eg it’s a server not a
>> workstation). Ideally the Dpc should run really quick, just getting
>> packets off the ring and giving them to NDIS is cpu and memory bandwidth
>> bound, but you have to make calls to NDIS and NDIS can take quite a
>> while to process the packets you give it.
>>
>
> There are some options (within my space) wrt tuning. And some knobs
> will be exposed to help with that. Right now the driver is still under
> development, so until that is completed and we get to play with system
> loads…
>
> Thanks,
> -PWM
>
>> James
>>
>>
>> —
>> 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
>
>
> Aren’t Linux tasklets more like Windows workitems?
Nothing even close to that - unlike workitmes, tasklets execute in atomic context so that you are not allowed to block. If you want to defer a job that has to make a blocking call you have to use workqueues and events that are basically dedicated driver threads and workitems, in Windows terms (the latter is just built on top of the former)
I thought the Linux “bottom half” interrupt handler was more equivalent to a Windows DPC?
“Bottom half” is a feature of 2.4 kernel. However, Linux 2.6 relies upon softirqs and tasklets, with the later built on top of the former - Linux just defines two dedicated softirqs of respectively highest and lowest priority Athough Linux allows the maximum 32 softirqs only 6 of them are actually used - 4 of them have their dedicated handlers and 2 remaining ones are used to implement tasklets. These 2 software interrupts have basically the same handlers that invoke tasklet routines. The reason why 2 interrupts, rather than a single one, a used is to allow you to decide how your tasklet’s priority fairs against that of other softirqs /tasklets.
Therefore, Linux tasklet is quite similar to DPC under Windows. The main difference between DPC and tasklet is that Windows allows concurrent execution of multiple instances of DPC routine while Linux would not execute a tasklet until tasklet procedure that runs on another CPU returns control. Once neither system would allow queuing DPC that is already enqueued and the OP is obviously from the Linux background, the quotation from MSDN confused him - apparently, it made him believe that DPC cannot start running until another instance of it that runs on another CPU returns control…
Anton Bassov
Anton,
Good answer in the last paragraph about Windows. I have no clue about
Linux, though.
For those who care that is the basic rule. A DPC can only be scheduled
once. A DPC once removed from the queue to run on a processor can be
scheduled. It can also be removed from the queue and execution begun on a
different processor than the first one. Windows will tell you if the DPC
cannot be scheduled and if you have data you need to keep, it is your job to
do it. Also watch out for miniports where the rules may be more restrictive
and even undocumented (or confusing documentation), even if they are using
the system DPC routines to implement parts of the code.
wrote in message news:xxxxx@ntdev…
>> Aren’t Linux tasklets more like Windows workitems?
>
> Nothing even close to that - unlike workitmes, tasklets execute in atomic
> context so that you are not allowed to block. If you want to defer a job
> that has to make a blocking call you have to use workqueues and events
> that are basically dedicated driver threads and workitems, in Windows
> terms (the latter is just built on top of the former)
>
>
>> I thought the Linux “bottom half” interrupt handler was more equivalent
>> to a Windows DPC?
>
> “Bottom half” is a feature of 2.4 kernel. However, Linux 2.6 relies upon
> softirqs and tasklets, with the later built on top of the former - Linux
> just defines two dedicated softirqs of respectively highest and lowest
> priority Athough Linux allows the maximum 32 softirqs only 6 of them are
> actually used - 4 of them have their dedicated handlers and 2 remaining
> ones are used to implement tasklets. These 2 software interrupts have
> basically the same handlers that invoke tasklet routines. The reason why 2
> interrupts, rather than a single one, a used is to allow you to decide how
> your tasklet’s priority fairs against that of other softirqs /tasklets.
>
> Therefore, Linux tasklet is quite similar to DPC under Windows. The main
> difference between DPC and tasklet is that Windows allows concurrent
> execution of multiple instances of DPC routine while Linux would not
> execute a tasklet until tasklet procedure that runs on another CPU returns
> control. Once neither system would allow queuing DPC that is already
> enqueued and the OP is obviously from the Linux background, the quotation
> from MSDN confused him - apparently, it made him believe that DPC cannot
> start running until another instance of it that runs on another CPU
> returns control…
>
> Anton Bassov
>
>
I recall that (for me) the most difficult synchronization aspect of DPCs to
get my head around when I first needed to was that a single DPC can
simultaneously be scheduled (waiting to be dispatched) *and* running on more
than one processor at once. Windows only ensures that it cannot be
‘scheduled’ twice which is to say the DPC object can only be on at most one
queue waiting to be dispatched. The DPC routine might be chugging along on
any, some, or all of the processors in the box depending on how the DPC
‘request’ operation is managed by a driver.
Dave Cattley
> I have no clue about Linux, though.
Please note that it moves pretty fast, so that all statements that I made on this thread may become obsolete pretty shortly - AFAIK, Linus already agreed to the idea of introducing BSD/Solaris-style interrupt threads
to the kernel, so that softirqs and tasklets may become the things of the past…
Anton Bassov
>
> Aren’t Linux tasklets more like Windows workitems?
Nothing even close to that - unlike workitmes, tasklets execute in
atomic
context so that you are not allowed to block. If you want to defer a
job that
has to make a blocking call you have to use workqueues and events that
are
basically dedicated driver threads and workitems, in Windows terms
(the latter
is just built on top of the former)
> I thought the Linux “bottom half” interrupt handler was more
equivalent to a
Windows DPC?
“Bottom half” is a feature of 2.4 kernel. However, Linux 2.6 relies
upon
softirqs and tasklets, with the later built on top of the former -
Linux just
defines two dedicated softirqs of respectively highest and lowest
priority
Athough Linux allows the maximum 32 softirqs only 6 of them are
actually used
- 4 of them have their dedicated handlers and 2 remaining ones are
used to
implement tasklets. These 2 software interrupts have basically the
same
handlers that invoke tasklet routines. The reason why 2 interrupts,
rather
than a single one, a used is to allow you to decide how your tasklet’s
priority fairs against that of other softirqs /tasklets.
Therefore, Linux tasklet is quite similar to DPC under Windows. The
main
difference between DPC and tasklet is that Windows allows concurrent
execution
of multiple instances of DPC routine while Linux would not execute a
tasklet
until tasklet procedure that runs on another CPU returns control. Once
neither
system would allow queuing DPC that is already enqueued and the OP is
obviously from the Linux background, the quotation from MSDN confused
him -
apparently, it made him believe that DPC cannot start running until
another
instance of it that runs on another CPU returns control…
Thanks Anton. I’ve said it before - some of the best answers I’ve ever
received on the internet are in response to something I’ve posted that’s
been dead wrong 
James
> some of the best answers I’ve ever received on the internet are in response to something
I’ve posted that’s been dead wrong
The same story with me. In fact, I have learned in awful lot in “heated debates” where I was wrong on quite a few occasions… IMHO, arguing is, probably, one of the best ways of learning things - you are being told XYZ that you don’t believe is true, so you do a bit of research and discover, that, in actuality, it is, despite all your claims to the contrary. Never mind - even if you turn out to be wrong in the end of the day, the knowledge you get as a result is definitely worth making a bit of a fool out of yourself…
Anton Bassov
>IMHO, arguing is, probably, one of the best ways of learning things
With proper argument culture - yes.
For a sample of improper argument culture, visit any Russian-language political forum (or politized blogs), or some Linux fans forum on “Microsoft must die” topic.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>
>IMHO, arguing is, probably, one of the best ways of learning things
With proper argument culture - yes.
For a sample of improper argument culture, visit any
Russian-language
political forum (or politized blogs), or some Linux fans forum on
“Microsoft
must die” topic.
To be fair to Linux fans, you don’t even have to mention Microsoft.
Simply asking a question like “Which is better - Debian or Redhat?” or
“Which is better - vi or emacs?” is sufficient to start a holy war on
most forums.
Seriously though, I subscribe to about 3 other mailing lists (Linux or
Open Source Software oriented) with similar traffic to ntdev, and in
terms of arguments degenerating beyond the point of learning anything,
there is nothing quite like ntdev. All of them have their moments of
course, but ntdev has a few more moments than the others
James