From: "p.hamshere" <p.hamshere@ntlworld.com>
To: linux-mm@kvack.org
Subject: Page allocation (get_free_pages)
Date: Wed, 18 Oct 2000 21:12:26 +0100 [thread overview]
Message-ID: <001b01c0393f$bc79ddc0$c958fc3e@brain> (raw)
[-- 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 --]
next reply other threads:[~2000-10-18 20:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-18 20:12 p.hamshere [this message]
2000-10-18 20:17 ` Timur Tabi
2000-10-18 20:46 ` afei
2000-10-19 9:40 ` ehrhardt
2000-10-19 12:31 ` Eric Lowe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='001b01c0393f$bc79ddc0$c958fc3e@brain' \
--to=p.hamshere@ntlworld.com \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox