Re: [ros-svn] [hbirr] 17306: - Removed the hole pool allocation, because it needs to much memory and ros will not boot.
hbirr@svn.reactos.com wrote:
- Removed the hole pool allocation, because it needs to much memory and ros will not boot.
- Allocate short blocks in one page.
- Split the used and free header. It makes it easier to implement a red zone check.
Can we use rpoolmgr.h for npool? I wrote it to be useable by both.
Royce Mitchell III wrote:
hbirr@svn.reactos.com wrote:
- Removed the hole pool allocation, because it needs to much memory
and ros will not boot. - Allocate short blocks in one page. - Split the used and free header. It makes it easier to implement a red zone check.
Can we use rpoolmgr.h for npool? I wrote it to be useable by both.
The non paged pool uses an avl tree for free blocks. That is very fast. Currently, I'm thinking about the red zone check and about moving the block headers into separate blocks. Currently we need to access 20..50 free headers to find one block. A cpu has between 8 and 40 tlb entries for data. If we move the headers into some single pages (or one large page), we prevent from tlb thrashing. Currently, Rpoolmgr.h doesn't implement the allocation of short blocks in a single page. This will break the using of the queues.
- Hartmut
Hartmut Birr wrote:
Royce Mitchell III wrote:
hbirr@svn.reactos.com wrote:
- Removed the hole pool allocation, because it needs to much memory
and ros will not boot. - Allocate short blocks in one page. - Split the used and free header. It makes it easier to implement a red zone check.
Can we use rpoolmgr.h for npool? I wrote it to be useable by both.
The non paged pool uses an avl tree for free blocks. That is very fast. Currently, I'm thinking about the red zone check and about moving the block headers into separate blocks. Currently we need to access 20..50 free headers to find one block. A cpu has between 8 and 40 tlb entries for data. If we move the headers into some single pages (or one large page), we prevent from tlb thrashing. Currently, Rpoolmgr.h doesn't implement the allocation of short blocks in a single page. This will break the using of the queues.
What about abstracting the npool code so that it can be used for ppool also? That way improvements to one would benefit both?
HI:
I have some code that used to work but haven't tested yet with recent ROS versions, Maybe it won't work anymore. I does that (all searches are in a couple of pages) and uses a bitmap for small blocks. I was never finished but you could get some ideas looking at that code. Anyway ROS does not consumes very mucho npool (except for drivers that are loaded) But I'm sure that if it is applied to ppool, will save us some Mbs.
Regards Waldo Alvarez
On 8/11/05, Royce Mitchell III royce3@ev1.net wrote:
Hartmut Birr wrote:
Royce Mitchell III wrote:
hbirr@svn.reactos.com wrote:
- Removed the hole pool allocation, because it needs to much memory
and ros will not boot. - Allocate short blocks in one page. - Split the used and free header. It makes it easier to implement a red zone check.
Can we use rpoolmgr.h for npool? I wrote it to be useable by both.
The non paged pool uses an avl tree for free blocks. That is very fast. Currently, I'm thinking about the red zone check and about moving the block headers into separate blocks. Currently we need to access 20..50 free headers to find one block. A cpu has between 8 and 40 tlb entries for data. If we move the headers into some single pages (or one large page), we prevent from tlb thrashing. Currently, Rpoolmgr.h doesn't implement the allocation of short blocks in a single page. This will break the using of the queues.
What about abstracting the npool code so that it can be used for ppool also? That way improvements to one would benefit both?
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
-
Hartmut Birr -
Royce Mitchell III -
waldo alvarez