Thanks.
http://article.gmane.org/gmane.linux.kernel.kernelnewbies/20028
Hi,
I'm porting my test memory allocator from i386 to
x86_64 (Xeon) systems for learning purposes. It
creates zone banks of 4K (single 4K pages) and 64K (16
4K pages virtually contiguous).
For this reason, I track them using a bitfield. Since
my system has 4GB of ram, allotting 1 bit per 4K page
helps me keep track of all the pages in a system
having 4GB of ram using only 128K of additional
memory.
On x86_64, since all memory is mapped from
0xffff810000000000 onwards, I believe if I assign a
bit for each 4K page from this address onwards, I can
track all pages in the system.
However, alloc_pages() returns address like
0xffff810106bce000 which falls out of the linear 4GB
range from 0xffff810000000000 onwards.
So it seems the memory mapping is not linear.
So my question is how do I know:
1) which is the lowest possible kernel virtual address
that can ever by allocated to by by
alloc_pages/get_free_pages?
2) is the kernel memory virtually contiguous?
3) if the kernel memory is not virtually contiguous,
how to I use simple bitfield and address math to keep
track of these disperse addresses?
Thanks
Rock
My attempted answer:
alloc_pages() is returning struct page*, which is ptr to the 64-bit range of memory on the location of the structure "page", and which is running when paging is enabled. Paging enabled means that MMU is used, and therefore, the memory ptr that returned is always subjected to the mercy of MMU translation mechanism, and therefore cannot be physical memory address. Inside the kernel, all memory ptr always traverse the entire 64-bit range (with a lot of illegal holes inside), irregardless of how much physical memory u have. U have to work backwards mathematically to derive the actual physical memory address, as all these are determined by the PMD/PUD tables setup to push the MMU translation mechanism. But the physical address u derived will always be limited to 4GB, which is what u have physically.
Hi,
I'm porting my test memory allocator from i386 to
x86_64 (Xeon) systems for learning purposes. It
creates zone banks of 4K (single 4K pages) and 64K (16
4K pages virtually contiguous).
For this reason, I track them using a bitfield. Since
my system has 4GB of ram, allotting 1 bit per 4K page
helps me keep track of all the pages in a system
having 4GB of ram using only 128K of additional
memory.
On x86_64, since all memory is mapped from
0xffff810000000000 onwards, I believe if I assign a
bit for each 4K page from this address onwards, I can
track all pages in the system.
However, alloc_pages() returns address like
0xffff810106bce000 which falls out of the linear 4GB
range from 0xffff810000000000 onwards.
So it seems the memory mapping is not linear.
So my question is how do I know:
1) which is the lowest possible kernel virtual address
that can ever by allocated to by by
alloc_pages/get_free_pages?
2) is the kernel memory virtually contiguous?
3) if the kernel memory is not virtually contiguous,
how to I use simple bitfield and address math to keep
track of these disperse addresses?
Thanks
Rock
My attempted answer:
alloc_pages() is returning struct page*, which is ptr to the 64-bit range of memory on the location of the structure "page", and which is running when paging is enabled. Paging enabled means that MMU is used, and therefore, the memory ptr that returned is always subjected to the mercy of MMU translation mechanism, and therefore cannot be physical memory address. Inside the kernel, all memory ptr always traverse the entire 64-bit range (with a lot of illegal holes inside), irregardless of how much physical memory u have. U have to work backwards mathematically to derive the actual physical memory address, as all these are determined by the PMD/PUD tables setup to push the MMU translation mechanism. But the physical address u derived will always be limited to 4GB, which is what u have physically.
--
Regards,
Peter Teoh
