Maxim,
The driver uses the common with Linux hardware lib and the kernel memory manager. It works mostly as a transport for user’s calls to hardware lib. The data is a row MPEG stream that is decoded inside the hardware decoder. So nobody calls any compress/decompress.
Regarding “RltCompressBuffer is NTFS file data compression” it was my first thougt to check if I have compress drive setting. Noway.
The main problem is significant increasing kernel mode time (to 20-30% of CPU - Kernel and Hal)with negligent absolute and relative driver/hardware lib time. The interrupt, DPC, locks time non significant as well. I also made manual profiling with a set of counters that did not show any real difference for the driver as such between the case of big and small memory pool. So I only blaim the kernel.
By the way KrView looks OK. At the beginning using it I found a couple of bootlenecks inside the driver and it was pinpointed exactly to the source of problems on function level.
Thanks,
Val
----- Original Message -----
From: Maxim S. Shatskih
To: Windows System Software Devs Interest List
Sent: Thursday, December 09, 2004 3:55 PM
Subject: Re: [ntdev] Excessive RtlCompressBuffer kernel CPU usage
Maybe a KrView bug.
BTW - the best way to write the data to the device is to send lots of overlapped writes to the file handle from user mode, the driver must be DIRECT_IO and feed these MDLs (Irp-MdlAddress) to DMA, making a huge scatter gather list from them. No need in common buffers except for a hardware-defined host-memory-based scatter-gather list (which most devices have, like aic78xx or OHCI1394, and even - in a trivial version - the IDE DMA).
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Valeriy Podkolzin
To: Windows System Software Devs Interest List
Sent: Friday, December 10, 2004 1:09 AM
Subject: [ntdev] Excessive RtlCompressBuffer kernel CPU usage
I have a driver that control a streaming chip board. The driver allocates a pool
of buffers in non-paged memory that is filled in an user application and
DMAed to the chip.
If I use 32 of 32KB buffers the overall CPU usage is less then 1% when the
application runs.
With reducing the number of buffer and the size, say, to 8 buffers of 2KB
the CPU usage increases to 20% and more. When I profile it using the latest
KrView packet I got that only 1% consumed by the driver and the rest 99%
consumed by the kernel. The biggest contribution that more 50% of kernel and
hal together is taken by RtlCompressBuffer function.
I wonder how come? I don’t use any compression. The system is 2 processor’s
running checked build of WinXP Professional SP1.
Thanks.
VP
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com