On 02/05/2013 09:32 PM, Mel Gorman wrote:
On Tue, Feb 05, 2013 at 11:57:22AM +0000, Mel Gorman wrote:
+ migrate_pre_flag = 1;
+ }
+
+ if (!isolate_lru_page(pages[i])) {
+ inc_zone_page_state(pages[i], NR_ISOLATED_ANON +
+ page_is_file_cache(pages[i]));
+ list_add_tail(&pages[i]->lru, &pagelist);
+ } else {
+ isolate_err = 1;
+ goto put_page;
+ }
isolate_lru_page() takes the LRU lock every time.
Credit to Michal Hocko for bringing this up but with the number of
other issues I missed that this is also broken with respect to huge page
handling. hugetlbfs pages will not be on the LRU so the isolation will mess
up and the migration has to be handled differently. Ordinarily hugetlbfs
pages cannot be allocated from ZONE_MOVABLE but it is possible to configure
it to be allowed via /proc/sys/vm/hugepages_treat_as_movable. If this
encounters a hugetlbfs page, it'll just blow up.
As you said, hugetlbfs pages are not in LRU list, then how can encounter
a hugetlbfs page and blow up?
The other is that this almost certainly broken for transhuge page
handling. gup returns the head and tail pages and ordinarily this is ok
When need gup thp? in kvm case?
because the caller only cares about the physical address. Migration will
also split a hugepage if it receives it but you are potentially adding
tail pages to a list here and then migrating them. The split of the first
page will get very confused. I'm not exactly sure what the result will be
but it won't be pretty.
Was THP enabled when this was tested? Was CONFIG_DEBUG_LIST enabled
during testing?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
