Messages in this thread | | | Date | Tue, 10 Oct 2006 19:15:52 +1000 | From | David Gibson <> | Subject | Re: Hugepage regression |
| |
On Tue, Oct 10, 2006 at 02:04:26AM -0700, Andrew Morton wrote: > On Tue, 10 Oct 2006 18:47:48 +1000 > David Gibson <david@gibson.dropbear.id.au> wrote: > > > It seems commit fe1668ae5bf0145014c71797febd9ad5670d5d05 causes a > > hugepage regression. A git bisect points the finger at that commit > > for causing an oops in the 'alloc-instantiate-race' test from the > > libhugetlbfs testsuite. > > > > Still looking to determine the reason it breaks things. > > > > It's assuming that unmap_hugepage_range() is always freeing these pages. > If the page is shared by another mapping, bad things will happen: the > threads fight over page->lru. > > Doing > > + if (page_count(page) == 1) > list_add(&page->lru, &page_list); > > might help. But then we miss the tlb flush in rare racy conditions.
Well, there'd need to be an else doing a put_page(), too.
Looks like the fundamental problem is that a list is not a suitable data structure for gathering here, since it's not truly local. We should probably change it to a small array, like in the normal tlb gather structure. If we run out of space we can force the tlb flush and keep going.
Or we could just give up on lazy tlb flush for hugepages.
-- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson - 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/
| |