I’m trying to improve my driver’s performance by reducing heap thrashing by not calling ExAllocatePool and ExFreePool (et. al.) everytime my driver wants to build a URB, which is frequently.
If I have a function that creates a URB and sends it via IoCallDriver( ), is there any problem creating a URB as a local as long as the IRP is complete by the time it returns?
I ask because this seems more efficient, but example code always shows dynamic allocation. Any thoughts?
No special problem. It is like any other stack variable. You have to ensure it isn’t accessed when code goes out of scope (i.e. always wait for IRP completion) and you must not overuse limited kernel stack.
I use it when handling synchronous IOCTL requests.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of xxxxx@comcast.net[SMTP:xxxxx@comcast.net]
Reply To: Windows System Software Devs Interest List
Sent: Monday, January 22, 2007 10:41 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Stack-Allocated URBsI’m trying to improve my driver’s performance by reducing heap thrashing by not calling ExAllocatePool and ExFreePool (et. al.) everytime my driver wants to build a URB, which is frequently.
If I have a function that creates a URB and sends it via IoCallDriver( ), is there any problem creating a URB as a local as long as the IRP is complete by the time it returns?
I ask because this seems more efficient, but example code always shows dynamic allocation. Any thoughts?
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
xxxxx@comcast.net wrote:
I’m trying to improve my driver’s performance by reducing heap thrashing by not calling ExAllocatePool and ExFreePool (et. al.) everytime my driver wants to build a URB, which is frequently.
If I have a function that creates a URB and sends it via IoCallDriver( ), is there any problem creating a URB as a local as long as the IRP is complete by the time it returns?
I ask because this seems more efficient, but example code always shows dynamic allocation. Any thoughts?
Yes, this is fine for synchronous URB calls. I do it all the time. I,
also, do not understand why the samples always allocate them dynamically.
This doesn’t work for isochronous URBs, which vary in length.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
It will probably be okay. Make sure you do a kernelmode wait rather than a user-mode (parameter to KeWaitForSingleObject) or you risk having your thread stack swap out while the I/O is in progress.
However if you’re deep in the call stack you should be careful. Kernel stack is limited and when you go over the limit you bugcheck the machine. Allocating large structures on the stack is frowned on from that point of view.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@comcast.net
Sent: Monday, January 22, 2007 1:41 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Stack-Allocated URBs
I’m trying to improve my driver’s performance by reducing heap thrashing by not calling ExAllocatePool and ExFreePool (et. al.) everytime my driver wants to build a URB, which is frequently.
If I have a function that creates a URB and sends it via IoCallDriver( ), is there any problem creating a URB as a local as long as the IRP is complete by the time it returns?
I ask because this seems more efficient, but example code always shows dynamic allocation. Any thoughts?
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Have you looked into using lookaside lists for this? This should give
you the efficiency you are looking for without blowing the kernel call
stack.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@comcast.net
Sent: Monday, January 22, 2007 1:41 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Stack-Allocated URBs
I’m trying to improve my driver’s performance by reducing heap thrashing
by not calling ExAllocatePool and ExFreePool (et. al.) everytime my
driver wants to build a URB, which is frequently.
If I have a function that creates a URB and sends it via IoCallDriver(
), is there any problem creating a URB as a local as long as the IRP is
complete by the time it returns?
I ask because this seems more efficient, but example code always shows
dynamic allocation. Any thoughts?
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
If you want to improve perf for asyn calls, create a lookaside and
allocate the URBs from it. If there are existing allocations in the
lookaside, the allocation from the list is “free”
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Monday, January 22, 2007 1:57 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Stack-Allocated URBs
No special problem. It is like any other stack variable. You have to
ensure it isn’t accessed when code goes out of scope (i.e. always wait
for IRP completion) and you must not overuse limited kernel stack.
I use it when handling synchronous IOCTL requests.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of xxxxx@comcast.net[SMTP:xxxxx@comcast.net]
Reply To: Windows System Software Devs Interest List
Sent: Monday, January 22, 2007 10:41 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Stack-Allocated URBsI’m trying to improve my driver’s performance by reducing heap
thrashing by not calling ExAllocatePool and ExFreePool (et. al.)
everytime my driver wants to build a URB, which is frequently.If I have a function that creates a URB and sends it via IoCallDriver(
), is there any problem creating a URB as a local as long as the IRP is
complete by the time it returns?I ask because this seems more efficient, but example code always shows
dynamic allocation. Any thoughts?
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Note that the kernel stack is a scarce resource. I would allocate
everything from heap.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> I’m trying to improve my driver’s performance by reducing heap thrashing by
not calling ExAllocatePool and ExFreePool (et. al.) everytime my driver wants
to build a URB, which is frequently.
>
> If I have a function that creates a URB and sends it via IoCallDriver( ), is
there any problem creating a URB as a local as long as the IRP is complete by
the time it returns?
>
> I ask because this seems more efficient, but example code always shows
dynamic allocation. Any thoughts?
>
Peter Wieland wrote:
It will probably be okay. Make sure you do a kernelmode wait rather than a user-mode (parameter to KeWaitForSingleObject) or you risk having your thread stack swap out while the I/O is in progress.
However if you’re deep in the call stack you should be careful. Kernel stack is limited and when you go over the limit you bugcheck the machine. Allocating large structures on the stack is frowned on from that point of view.
A URB is only 96 bytes.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.