I'm just a little lost. Iff the hardware/mmu/page table entry supports
multiple page sizes, then why don't you just ...
* Identify the amount of physical memory
* Read a config file to determine a non-default number of
larger than mininum page sizes,
* Else allocate sections of physical memory to support
large page sizes at initialization time.
Each page size should have the same logic behind the
request of the page, replacement of the page, etc.
* Even very large physical memory's could have multiple
freelists for even the same size of page,
* Thus the spare CPU could age the pages of a particular
freelist,
* In addition, a special type of page could belong to a
certain type of freelist that once allocated would not
be freed because of its usage. This would in effect
lock down the page and eliminate it and other pages of
its type from even being search/aged.
* If one looks at memory on a normal functioning system
after some period of time,
the physical memory is normally filled with many
small holes that would prevent the allocation of
large pages, even if the system can support it.
And yes, I am "playing" with this multiple page size
support and multiple freelist idea on one of my systems.
The only real problem that I have is that the freelists
are currently aging at different rates. I am slowly
looking at this... And lastly, no I have not given this
code to anyone..
Mitchell Erblich
> -
> 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/
-
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/