Page allocation (get_free_pages)

Page allocation (get_free_pages)

[p.hamshere]

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

Hi
I'm wondering why get_free_pages allocates contiguous pages for non-DMA transfers and why the kernel identity (ish) maps the whole (up to 1GB) of physical memory to its address space...
Surely only DMA requires physically contiguous memory, and everything else (such as kernel stack) could be allocated via a 'vmalloc' like function. If this could be done cleverly, contiguous blocks could be held for DMA and the rest would be allocated from the random free pages left throughout the system. 
Also, the kernel only *needs* to identity map its code and data, and all other free pages can be mapped anywhere at will - surely?
Given the large blocks may be more 'permanent' than single page allocation / deallocation (on the assumption they are needed to be present for DMA), then also the allocation could be slower and perhaps work on a best-fit algorithm. This then might remove the 'power of two' alignment dependency in the get_free_page allocation.
I know I'm missing something (extra overhead of remapping physical memory in the kernel page tables, lack of identity mapping and the fact the kernel assumes this, tracking of physical memory, my Intel-centric view of the world misses the MIPS architecture  -something)...but what is it?
Reading some books on page allocation it seems that some oses do not allocate contiguous page ever, including NT by the looks of it - do they just fudge the DMA into smaller chunks - anyone know?
Paul

[-- Attachment #2: Type: text/html, Size: 2104 bytes --]

Re: Page allocation (get_free_pages)

[Timur Tabi]

** Reply to message from "p.hamshere" <p.hamshere@ntlworld.com> on Wed, 18 Oct
2000 21:12:26 +0100


> I'm wondering why get_free_pages allocates contiguous pages for non-DMA transfers and why the kernel identity (ish) maps the whole (up to 1GB) of physical memory to its address space...

I can't answer the question as to why, although I suspect because it's a lot
easier,

I can say, however, that if gfp were to not return contiguous pages, it would
break my driver.



-- 
Timur Tabi - ttabi@interactivesi.com
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please direct the reply to the mailing list only.  Don't send another copy to me.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Page allocation (get_free_pages)

[afei]

The reason for allocation of contiguous memory block is related to page
fault handling of certain machine instructions? I am not very sure either.

Fei Liu


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Page allocation (get_free_pages)

[ehrhardt]

[ I inserted a few newlines in the quoted text ]

On Wed, Oct 18, 2000 at 09:12:26PM +0100, p.hamshere wrote:
> Hi
> I'm wondering why get_free_pages allocates contiguous pages for non-DMA
> transfers and why the kernel identity (ish) maps the whole (up to 1GB)
> of physical memory to its address space...

Messing with page tables is sloooow and you probably won't gain too much:
About 95% of all gfp allocations are single page anyway. A typical 2 page
(order 1) allocation is the task struct of a new process.
Now look what happens if we implement your idea:
We allocate one ore more physical pages, search for some free space in
the kernel's virtual address space and update the kernel page tables as
needed. Compare this to just grabbing the page from the free list and
toggling a few bits in the buddy bitmaps.

      regards   Christian

-- 

THAT'S ALL FOLKS!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Page allocation (get_free_pages)

[Eric Lowe]

Hello,

> I'm wondering why get_free_pages allocates contiguous pages for non-DMA transfers and why the kernel identity (ish) maps the whole (up to 1GB) of physical memory to its address space...
> Surely only DMA requires physically contiguous memory, and everything else (such as kernel stack) could be allocated via a 'vmalloc' like function. If this could be done cleverly, contiguous blocks could be held for DMA and the rest would be allocated from the random free pages left throughout the system. 
> Also, the kernel only *needs* to identity map its code and data, and all other free pages can be mapped anywhere at will - surely?
> Given the large blocks may be more 'permanent' than single page allocation / deallocation (on the assumption they are needed to be present for DMA), then also the allocation could be slower and perhaps work on a best-fit algorithm. This then might remove the 'power of two' alignment dependency in the get_free_page allocation.

The lower 1GB is mapped into the kernel address space for convenience--
unlike *BSD, Linux has access to kernel memory without mapping it
below 1GB all the time, and only needs to create temporary
mappings for accessing high memory.  I'm not sure about non x86
differences since I am just beginning to play with those ports now.

> I know I'm missing something (extra overhead of remapping physical memory in the kernel page tables, lack of identity mapping and the fact the kernel assumes this, tracking of physical memory, my Intel-centric view of the world misses the MIPS architecture  -something)...but what is it?
> Reading some books on page allocation it seems that some oses do not allocate contiguous page ever, including NT by the looks of it - do they just fudge the DMA into smaller chunks - anyone know?
> Paul

Creating mappings and destroying them is inefficient, mostly because
of TLB flushes (which are _very_ expensive on 4+way CPU boxen).
You'll find that the highmem code for Intel boxes use an LRU set
of mappings to avoid TLB flushes unless absolutely necessary --
it waits until a map absolutely must be flushed to avoid corruption
before doing it.  If the rest of memory were not mapped and
contiguous, this inefficiency would be propagated to code beyond
the highmem case.  If you really WANT virtual memory, you CAN
get it with vmalloc().  However as noted >95% of all normal kernel
allocations are for < PAGE_SIZE anyway.

--
Eric Lowe
Software Engineer, Systran Corporation
elowe@systran.com


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/