From: Maxim S. Shatskih on
>Also, I use MmAllocateContiguousMemorySpecifyCache: gives you more
>flexibility, you may not need that your memory is cached.

->AllocateCommonBuffer is a proper way.

On x86 and x64, there is no need in uncached DMA memory.

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

From: mirage2k2 on
I should probably tell you a bit more about my driver, it is an ndis
intermediate driver, I do not use DMA or deal directly with any hardware. I
need to allocate large chunks of contiguous memory that will be accessed at
DISPATCH_LEVEL. It must be completely contiguous. I dont necessarily need
one 64MB chunk but I might need 4 * 16MB ... and not necessarily all at once
.... what I really need is a failsafe way of getting chunks of at least 16MB.
I'm guessing that after a few days of system up-time even this might fail.

I'm currently using NdisAllocateMemoryWithTag() but I'm considering changing
this to MmAllocateContiguousMemory() because it sounds like this function is
far more likely to succeed. I dont care at all if this functions is special
and should only be used for DMA ... if it works I will use it.

I dont like the idea of allocating 32MB-64MB at startup because I dont want
to hog it. If the system only has 128MB of non-paged pool I can't just take
half!

Mirage2k2

"mirage2k2" wrote:

> The documentation on MmAllocateContiguousMemory says that it attempts to
> allocate memory from the non-paged pool, and if this fails then "it attempts
> to perform the allocation from available unused pages".
>
> Firstly, what on earth does that mean? Secondly, will the memory "from
> available unused pages" still be non-paged? I will be accessing it at
> DISPATCH_LEVEL so I need to be certain.
>
> My guess is that the memory available in "unused pages" is somehow mapped
> into the non-paged pool ... thus increasing the size of the pool.
>
>
> My next question is about the size of the non-paged pool. I've read a few
> articles that suggest that there is a limit of 250MB, irrespective of total
> RAM. Does anyone know if there is a way of changing the configuration of
> the system to make this value higher, i.e. some weird registry setting or
> some system API call.
>
> Basically I need to allocate between 32MB - 64MB of non-paged memory, at any
> given time, and I need it to work. Allocating the memory in DriverEntry at
> startup is probably my best shot but there will be times when I don't need to
> allocate anything at all ... I don't want to allocate 32MB and then never use
> it ... or hog it until I do need it.
>
> Does anyone have any ideas?
> Thanks
> Mirage2k
>
From: Maxim S. Shatskih on
>I should probably tell you a bit more about my driver, it is an ndis
> intermediate driver, I do not use DMA or deal directly with any hardware.

Then you do not need contiguous memory.

>I need to allocate large chunks of contiguous memory that will be accessed at
> DISPATCH_LEVEL.

No, you need to allocate just _large chunks of nonpaged memory_, regardless of whether it is contiguous or not.

>It must be completely contiguous.

No, it must not.

Your driver is hardware-less and thus it is never mind on what physical pages underly its allocated region.

> I'm currently using NdisAllocateMemoryWithTag() but I'm considering changing
> this to MmAllocateContiguousMemory() because it sounds like this function is
> far more likely to succeed.

Just plain vice versa. MmAllocateContiguousMemory will fail if the physical memory pages are present but not contiguous. NdisAllocateMemoryWithTag (==ExAllocatePoolWithTag) will succeed in this case.

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

From: Doron Holan [MSFT] on
why does the memory need to be physically contiguous if you are a software
only driver? it will be virtually contiguous obviously...why is that not
enough?

--

This posting is provided "AS IS" with no warranties, and confers no rights.


"mirage2k2" <mirage2k2(a)discussions.microsoft.com> wrote in message
news:B05E86CC-24D2-4F25-917B-EF30817494EB(a)microsoft.com...
> I should probably tell you a bit more about my driver, it is an ndis
> intermediate driver, I do not use DMA or deal directly with any hardware.
> I
> need to allocate large chunks of contiguous memory that will be accessed
> at
> DISPATCH_LEVEL. It must be completely contiguous. I dont necessarily
> need
> one 64MB chunk but I might need 4 * 16MB ... and not necessarily all at
> once
> ... what I really need is a failsafe way of getting chunks of at least
> 16MB.
> I'm guessing that after a few days of system up-time even this might fail.
>
> I'm currently using NdisAllocateMemoryWithTag() but I'm considering
> changing
> this to MmAllocateContiguousMemory() because it sounds like this function
> is
> far more likely to succeed. I dont care at all if this functions is
> special
> and should only be used for DMA ... if it works I will use it.
>
> I dont like the idea of allocating 32MB-64MB at startup because I dont
> want
> to hog it. If the system only has 128MB of non-paged pool I can't just
> take
> half!
>
> Mirage2k2
>
> "mirage2k2" wrote:
>
>> The documentation on MmAllocateContiguousMemory says that it attempts to
>> allocate memory from the non-paged pool, and if this fails then "it
>> attempts
>> to perform the allocation from available unused pages".
>>
>> Firstly, what on earth does that mean? Secondly, will the memory "from
>> available unused pages" still be non-paged? I will be accessing it at
>> DISPATCH_LEVEL so I need to be certain.
>>
>> My guess is that the memory available in "unused pages" is somehow mapped
>> into the non-paged pool ... thus increasing the size of the pool.
>>
>>
>> My next question is about the size of the non-paged pool. I've read a
>> few
>> articles that suggest that there is a limit of 250MB, irrespective of
>> total
>> RAM. Does anyone know if there is a way of changing the configuration
>> of
>> the system to make this value higher, i.e. some weird registry setting or
>> some system API call.
>>
>> Basically I need to allocate between 32MB - 64MB of non-paged memory, at
>> any
>> given time, and I need it to work. Allocating the memory in DriverEntry
>> at
>> startup is probably my best shot but there will be times when I don't
>> need to
>> allocate anything at all ... I don't want to allocate 32MB and then never
>> use
>> it ... or hog it until I do need it.
>>
>> Does anyone have any ideas?
>> Thanks
>> Mirage2k
>>
From: mirage2k2 on
To be honest, I don't really know the difference between physically
contiguous and virtually contiguous ... I guess virtually contiguous is
fragmented blocks that are somehow made to look like one big block.

Anyway, I'm using the memory as a packet data history buffer ... I use
offsets into it, I search for recurring patterns in it, I might also need to
iterate all the way through it (by incrementing a UCHAR pointer) ... to me
this sounds like it needs to be physically contiguous. I also need to do all
of this in my packet receive/send handlers which run @ DISPATCH_LEVEL.

Any comments?
Mirage2k.



"Doron Holan [MSFT]" wrote:

> why does the memory need to be physically contiguous if you are a software
> only driver? it will be virtually contiguous obviously...why is that not
> enough?
>
> --
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "mirage2k2" <mirage2k2(a)discussions.microsoft.com> wrote in message
> news:B05E86CC-24D2-4F25-917B-EF30817494EB(a)microsoft.com...
> > I should probably tell you a bit more about my driver, it is an ndis
> > intermediate driver, I do not use DMA or deal directly with any hardware.
> > I
> > need to allocate large chunks of contiguous memory that will be accessed
> > at
> > DISPATCH_LEVEL. It must be completely contiguous. I dont necessarily
> > need
> > one 64MB chunk but I might need 4 * 16MB ... and not necessarily all at
> > once
> > ... what I really need is a failsafe way of getting chunks of at least
> > 16MB.
> > I'm guessing that after a few days of system up-time even this might fail.
> >
> > I'm currently using NdisAllocateMemoryWithTag() but I'm considering
> > changing
> > this to MmAllocateContiguousMemory() because it sounds like this function
> > is
> > far more likely to succeed. I dont care at all if this functions is
> > special
> > and should only be used for DMA ... if it works I will use it.
> >
> > I dont like the idea of allocating 32MB-64MB at startup because I dont
> > want
> > to hog it. If the system only has 128MB of non-paged pool I can't just
> > take
> > half!
> >
> > Mirage2k2
> >
> > "mirage2k2" wrote:
> >
> >> The documentation on MmAllocateContiguousMemory says that it attempts to
> >> allocate memory from the non-paged pool, and if this fails then "it
> >> attempts
> >> to perform the allocation from available unused pages".
> >>
> >> Firstly, what on earth does that mean? Secondly, will the memory "from
> >> available unused pages" still be non-paged? I will be accessing it at
> >> DISPATCH_LEVEL so I need to be certain.
> >>
> >> My guess is that the memory available in "unused pages" is somehow mapped
> >> into the non-paged pool ... thus increasing the size of the pool.
> >>
> >>
> >> My next question is about the size of the non-paged pool. I've read a
> >> few
> >> articles that suggest that there is a limit of 250MB, irrespective of
> >> total
> >> RAM. Does anyone know if there is a way of changing the configuration
> >> of
> >> the system to make this value higher, i.e. some weird registry setting or
> >> some system API call.
> >>
> >> Basically I need to allocate between 32MB - 64MB of non-paged memory, at
> >> any
> >> given time, and I need it to work. Allocating the memory in DriverEntry
> >> at
> >> startup is probably my best shot but there will be times when I don't
> >> need to
> >> allocate anything at all ... I don't want to allocate 32MB and then never
> >> use
> >> it ... or hog it until I do need it.
> >>
> >> Does anyone have any ideas?
> >> Thanks
> >> Mirage2k
> >>
> .
>