> Chop memory into 4Mb sized chunks that hold the perfectly normal
> and existing pages and buddy memory allocator. Set a flag on
> 25-33% of them to a max of say 10 and for <12Mb boxes simply say
> "tough".
We might also want to flag non-cached and dma areas too.
That way we can hand cached, non-dma memory to the kernel,
use non-cached stuff for buffer memory and page tables,
keeping dma-able memory relatively clean and keeping the
kernel (and critical pages) fast.
Maybe the execute bit should also have some influence on
placement. Having executable text in uncached memory may
well give a larger performance penalty than putting user
data there...
In my zone allocator design I have outlined 5 or 7 (depending
on how you look at it) different memory usages for the Linux
kernel. You might want to check that out to see if you've
overlooked something:
http://www.nl.linux.org/~riel/zone-alloc.html
> The performance impact of that on free page requests seems to be
> pretty minimal. In actual fact it wil help performance in some
> cases since the machine can't easily be killed by going out of non
> kernel space allocations - the 25% is also a "can do work" sanity
> check.
It's very well possible to keep separate free memory stats
and free memory from the different area's as needed.
cheers,
Rik -- If a Microsoft product fails, who do you sue?
+-------------------------------------------------------------------+
| Linux memory management tour guide. riel@nl.linux.org |
| Scouting Vries cubscout leader. http://www.nl.linux.org/~riel |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/