Messages in this thread | | | Date | Fri, 23 Apr 2004 04:28:12 -0700 | From | William Lee Irwin III <> | Subject | Re: put_page() tries to handle hugepages but fails |
| |
On Fri, Apr 23, 2004 at 03:35:22AM -0700, Andrew Morton wrote: >> Sure. >> This of course duplicates huge_page_release(), which can be killed off.
On Fri, Apr 23, 2004 at 03:47:44AM -0700, William Lee Irwin III wrote: > Ah, but mm/hugetlb.c is putting the destructor in head->lru.prev not > head[1].mapping; fix below along with nuking huge_page_release().
I just noticed a general problem where ->mapping is often referred to naked and so either needs to be filled in for the base pages of the superpage or the examiners need to be referred to the head of the superpage. Likewise with ->index, which is apparently now used to hold the order. In general, if they're superpage properties, either the examiners must be referred to the head of the superpage, or (wastefully) the values must be replicated across the base pages. The current scheme to prevent radix tree deadlocks and other nastinesses with multiple insertions (e.g. inserting an entry into the radix tree for each base page, which I've seen naive abuses of shit themselves several times before) reduces the resolution of the pagecache indices, which is problematic in various ways with respect to finding the right base page without updating excessive numbers of callers. The reason why this is less of a problem than it sounds like is that the base page lookups usually go through pagetables, which effectively act either as radix trees with an insertion for each base page (normal cpus) or radix trees with low- resolution indices with procedural API's to recover offsets into the superpage and the proper base page (i386, ppc64).
I'll be off the net all weekend, so hopefully the interested parties can use this info to resolve the remainder of the hugetlb put_page() issues. The work here is just cleaning up self-inconsistencies so it's not hard.
-- 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/
| |