Prev: driver installation failed in xp with 7600.16385.0 build environme
Next: kernel base address
From: m on 5 Mar 2010 23:18
My apologies: When i first saw your post, i assumed that you were using
these buffers to do content filtering as part of some kind of firewall
driver and derided the design as wasteful (notwithstanding my opinion of
security software in general); but you have been trying to develop something
altogether more useless and damaging!

As Maxim has pointed out, a differential algorithm is useless for packet
compression, and for stateless packet compression a single packet sized
buffer is sufficient. Of course stateless packet compression is mostly
useless unless you are trying to avoid fragmentation on media with
nonstandard MTU or you need to add encapsulation headers.

As Don has pointed out, while the is no problem using tens or hundreds of
megabytes of memory when it is needed, in KM every page should be valued and
conserved since excessive consumption of these resources impairs the ability
of the kernel to service applications.

Please don't take my jest personally, but it is humorous to see how much
havoc one simple question can cause!

"mirage2k2" <mirage2k2(a)discussions.microsoft.com> wrote in message
news:43D91949-1E3E-48D1-8752-D72091BB0051(a)microsoft.com...
> Firstly, I do not need 100's of MB, I need 32-64MB. Secondly, it is not
> my
> design, I have been provided with a compression/decompression library
> which
> requires me to allocate memory for packet history (1 history buffer for
> compressing outbound packets and 1 for decompressing inbound packets).
>
> I do not think it is acceptable for my driver to use a large percentage of
> available resources ... and this is why I've posted ... I'm looking for
> alternatives to non-paged pool.
>
> What I will probably do is limit my history buffer to about 16MB on xp
> 32-bit. I might allocate 1 history buffer from non-paged pool and the
> other
> from paged pool ... one buffer can typically be larger than the other ...
> the
> biggest one will come from paged pool. I will try to limit total
> allocation
> (on xp 32-bit) to about 32MB.
>
> Mirage2k2.
>
> "Don Burn" wrote:
>
>> So you think it is acceptable to take most of the memory that can be
>> allocated in the kernel for your driver to keep packet history?
>> Remember,
>> in most systems out there you can have 128MB total of non-paged pool and
>> 256MB of paged pool. Consider that XP still runs on a lot of systems
>> with
>> 512MB total. Even if the systems have a ton of memory you are taking a
>> large portion on 32-bit of the address space of the kernel since that is
>> 2GB.
>>
>> So no matter how you look at this your design is flawed.
>>
>>
>> Don Burn (MVP, Windows DKD)
>> Windows Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>>
>>
>>
>> > -----Original Message-----
>> > From: mirage2k2 [mailto:mirage2k2(a)discussions.microsoft.com]
>> > Posted At: Friday, March 05, 2010 7:16 AM
>> > Posted To: microsoft.public.development.device.drivers
>> > Conversation: MmAllocateContiguousMemory and non-paged pool size
>> > Subject: Re: MmAllocateContiguousMemory and non-paged pool size
>> >
>> > the huge megabytes are for packet history, the larger the history the
>> > better the compression. Anyway, thanks for all your help. I now do
>> > this and it
>> > works ok ...
>> >
>> > PMDL mdl;
>> > UCHAR *testPagedMem = (
>> > (UCHAR *)ExAllocatePoolWithTag(PagedPool, MEM_SIZE, 'aaa1') ); if
>> > (testPagedMem == 0) {
>> > return;
>> > }
>> >
>> > mdl = IoAllocateMdl(testPagedMem, MEM_SIZE, FALSE, FALSE, 0); if (mdl
>> > == 0) {
>> > return;
>> > }
>> >
>> > MmProbeAndLockPages(mdl, KernelMode, IoWriteAccess);
>> >
>> > Mirage2k
>> >
>> > "Maxim S. Shatskih" wrote:
>> >
>> > > >I need to decompress a compressed inbound packet in my receive
>> > packet
>> > > >handler
>> > >
>> > > Then why do you need these huge megabytes?
>> > >
>> > > Allocate the space enough for, say, 100 packets - i.e. 150KB.
>> > >
>> > > --
>> > > Maxim S. Shatskih
>> > > Windows DDK MVP
>> > > maxim(a)storagecraft.com
>> > > http://www.storagecraft.com
>> > >
>> > > .
>> > >
>> >
>> >
>> > __________ Information from ESET Smart Security, version of virus
>> > signature database 4917 (20100305) __________
>> >
>> > The message was checked by ESET Smart Security.
>> >
>> > http://www.eset.com
>> >
>>
>> .
>>
First  |  Prev  | 
Pages: 1 2 3 4
Prev: driver installation failed in xp with 7600.16385.0 build environme
Next: kernel base address