Using zones in NTOS

[Aliberti Emanuele]

What are the advantages in using zones when allocating memory in kernel 
mode?
Are there other ways to pre-allocate an address range to be used for 
small memory objects management (NP pool)?

Emanuele

[KJK::Hyperion]

At 14.48 23/10/2004, you wrote:
> What are the advantages in using zones when allocating memory in kernel mode?

I assume you use "zone" as the old word for "lookaside lists". Since there 
only are two possible kernel-mode pools vs infinite user-mode heaps, they 
are a way to have a sort of specialized "private heap" for frequent, small 
allocations (like IRPs and MDLs). They spare you frequent calls to the 
heavier (and globally locking - I don't know if reentrancy issues allow you 
to have a lock-free implementation) pool allocator
> Are there other ways to pre-allocate an address range to be used for small 
> memory objects management (NP pool)?

Aside from rolling your own, no. Lookaside lists would still have the 
advantage of being traced and profiled

[Aliberti Emanuele]

KJK::Hyperion wrote:
> Are there other ways to pre-allocate an address range to be used for 
> small memory objects management (NP pool)?
>
> Aside from rolling your own, no. Lookaside lists would still have the 
> advantage of being traced and profiled

They seem what I need, but how do I set an upper limit in pool charge 
for a lookaside list? Can it grow indefinitely?

Emanuele

[KJK::Hyperion]

At 22.28 25/10/2004, you wrote:
> > Aside from rolling your own, no. Lookaside lists would still have the 
> > advantage of being traced and profiled
>
> They seem what I need, but how do I set an upper limit in pool charge for 
> a lookaside list?

define your own allocator (Allocate and Free parameters to 
ExInitializePagedLookasideList)

[Aliberti Emanuele]

KJK::Hyperion wrote:
> At 22.28 25/10/2004, you wrote:
> > > Aside from rolling your own, no. Lookaside lists would still have 
> > > the advantage of being traced and profiled
> >
> > They seem what I need, but how do I set an upper limit in pool charge 
> > for a lookaside list?
>
> define your own allocator (Allocate and Free parameters to 
> ExInitializePagedLookasideList)

Really a nice solution! I can count how-much I de-/allocate and fail 
programmatically when the total is simply more than the set maximum pool 
charge.
thank you

[Casper Hornstrup]

Zones are pre-NT4 APIs. Microsoft recomends using lookaside lists instead.
Several ReactOS components use them (TCP/IP driver, storage stack and ntoskrnl to name a few).

Casper
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Aliberti Emanuele
> Sent: 23. oktober 2004 14:48
> To: [e-mail]
> Subject: [ros-dev] Using zones in NTOS
>
> What are the advantages in using zones when allocating memory 
> in kernel mode?
> Are there other ways to pre-allocate an address range to be 
> used for small memory objects management (NP pool)?
>
> Emanuele
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[Aliberti Emanuele]

Casper Hornstrup wrote:
> Zones are pre-NT4 APIs. Microsoft recomends using lookaside lists instead.
> Several ReactOS components use them (TCP/IP driver, storage stack and ntoskrnl to name a few).

Thank you for remembering me that zones are absolete. This explains why 
they are implemented in ROS with macros.

Among obsolete kernel APIs, I found ROS code often uses ExAllocatePool, 
which is marked as obsolete in the DDK. They suggest tagging memory 
wherever you allocate a block.

Emanuele