DPC vs tasklet

['Christoph Hellwig']

"usage of tasklet itself is questionable, you probably want a kernel-thread"
and redo our driver bottom half discovery handler to use a DPC. I just
wanted to get your opinion of why usage of a tasklet is questionable. Some
of the LINUX documentation I've read states "tasklets are the preferred
mechanism with which to implement your bottom half for a normal hardware
device". I can see, as you stated, being in user context will help with
things like allowing the use of GFP_KERNEL for memory allocations or safe
calling of del_timer_sync(); but its not real clear to me what all the
tradeoffs are and why some people think tasklets are the preferred
mechanism. Can you shed some more light on this or direct me to some URLs
with more info.

tasklets run at softirq time which means you don't want to do too much
work there, in addition to making locking and memory allocation more
difficult for you. Given that you're doing lots of processing in there
a kernel thread seems like the better choice. The kernelthread also
has the advtantage that you can bind it to the cpu the irq happens on
to avoid lots of cacheline bouncing.

In the end you probably want to benchmark the different variants against
each other.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Arjan van de Ven]

Christoph,
"usage of tasklet itself is questionable, you probably want a kernel-thread"

well there's a few angles here:
1) For IO completion (eg the common, fastpath case), you don't want to
use a tasklet OR kernel-thread, just do the completion right there and
then in the ISR, since the scsi layer completion handler you call will
queue it for real work, the final completion, by the scsi softirq
already.

2) For management work, I can see the point of doing it in a
kernel-thread, since it's 1) rare (eg slowpath) 2) complex 3) code that
might want long-ish delays or allocate memory, neither of which you want
in irq context.

[Jeff Garzik]

Post by Arjan van de Ven
1) For IO completion (eg the common, fastpath case), you don't want to
use a tasklet OR kernel-thread, just do the completion right there and
then in the ISR, since the scsi layer completion handler you call will
queue it for real work, the final completion, by the scsi softirq
already.

Agreed, presuming that the IO completion is fairly cheap.

Post by Arjan van de Ven
2) For management work, I can see the point of doing it in a
kernel-thread, since it's 1) rare (eg slowpath) 2) complex 3) code that
might want long-ish delays or allocate memory, neither of which you want
in irq context.

Agreed.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Infante, Jon]

FC discovery is a rare occurance and potentially pretty complex. Based on
the input from everyone I feel much more confident about making it a DPC.
Thanks.
Jon

-----Original Message-----
From: Jeff Garzik [mailto:***@pobox.com]
Sent: Thursday, May 20, 2004 10:58 AM
To: ***@redhat.com
Cc: Infante, Jon; 'Christoph Hellwig'; Smart, James;
'linux-***@vger.kernel.org'
Subject: Re: DPC vs tasklet

Post by Arjan van de Ven
1) For IO completion (eg the common, fastpath case), you don't want to
use a tasklet OR kernel-thread, just do the completion right there and
then in the ISR, since the scsi layer completion handler you call will
queue it for real work, the final completion, by the scsi softirq
already.

Agreed, presuming that the IO completion is fairly cheap.

Post by Arjan van de Ven
2) For management work, I can see the point of doing it in a
kernel-thread, since it's 1) rare (eg slowpath) 2) complex 3) code that
might want long-ish delays or allocate memory, neither of which you want
in irq context.

Agreed.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html