MmAllocateMappingAddress() and MmProbeAndLockPages()

NTDEV
21

I suspect walking your linked list of pages and freeing the slab would be faster than mucking around with page tables.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@Yahoo.com
Sent: Wednesday, September 15, 2010 3:57 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmAllocateMappingAddress() and MmProbeAndLockPages()

Yeah, that was the original idea. But freeing a page within a slab is kinda slow because you have to traverse through a linked list of slabs. That’s were the VA space idea came in – to make freeing a page very fast.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

22

@PV:

Well… hmmm… the question is WHY it’s slow.

I suspect that a page-aligned alloc may not have a prefix that describes it. The descriptor is most likely kept in a side list, which might be single linked, which could explain its poor performance. For best performance, that better be an AVL tree. It might already be in a more recent OS.

23

AVL tree – cool. I just found it on the MSDN website under “Other System Structures”.

Thanks,

((&->

24

In an attempt to answer the question of why ExFreePoolWithTag() is slow:

We are running a stress test application for 3 hours which causes the kernel-level data structure to grow from about 900 MB to 10 GB. I suspect that the non-paged pool memory is very fragmented and this may be the cause of the slow down.

25

There’s an excellent OSRONLINE.COM article on AVL/Splay trees.

http://www.osronline.com/article.cfm?article=516

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@Yahoo.com
Sent: Wednesday, September 15, 2010 7:16 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmAllocateMappingAddress() and MmProbeAndLockPages()

In an attempt to answer the question of why ExFreePoolWithTag() is slow:

We are running a stress test application for 3 hours which causes the
kernel-level data structure to grow from about 900 MB to 10 GB. I suspect
that the non-paged pool memory is very fragmented and this may be the cause
of the slow down.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

26

> Yeah, that was the original idea. But freeing a page within a slab is kinda slow because you have to

traverse through a linked list of slabs.

Why? keep the slab pointer in the page’s header or trailer.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

27

>Why? keep the slab pointer in the page’s header or trailer.

If the allocation takes a whole page, the header/trailer can’t be attached to it without wasting too much memory. Then the descriptor has to be kept in a side list, which might be too slow to search.

28

In my implementation, the first page of the slab contains things like the bitmap of free pages, the link to the next/prev slab, and other managerial info. I could have put this somewhere else, but this seemed like the most logical place. This way, I only have to do one allocation operation for the header and all of the pages, instead of two separate allocations. It somewhat simplifies the code.