Messages in this thread | | | Date | Tue, 9 Mar 2004 00:44:59 -0800 | From | William Lee Irwin III <> | Subject | Re: objrmap-core-1 (rmap removal for file mappings to avoid 4:4 in <=16G machines) |
| |
On Tue, Mar 09, 2004 at 09:31:03AM +0100, Ingo Molnar wrote: > with rmap we do have the ability to make it truly O(1) all across, by > making the pte chains a double linked list. Moreover, we can freely > reduce the rmap overhead (both the memory, algorithmic and locking > overhead) by increasing the page size - a natural thing to do on big > boxes anyway. The increasing of the page size also linearly _reduces_ > the RAM footprint of rmap. So rmap and pgcl are a natural fit and the > thing of the future. > now, the linear searching of vmas does not reduce with increased > page-size. In fact, it will increase in time as the sharing factor > increases.
This is getting bandied about rather frequently. I should make some kind of attack on an implementation. The natural implementation is to add one pte per contiguous and aligned group of PAGE_MMUCOUNT ptes to the pte_chain and search the area surrounding any pte_chain element.
But the linear search you're pointing at is unnecessary to begin with. Only the single nonlinear mappings' pte needs to be added to the pte_chain there; one need only also scan the vma lists at reclaim-time. This would also make page_convert_anon() a misnomer and SetPageAnon() on nonlinearly-mapped file-backed pages a bug.
-- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |