Messages in this thread | | | Date | Wed, 20 Feb 2013 17:58:22 +0800 | From | Simon Jeons <> | Subject | Re: [PATCH 1/2] mm: hotplug: implement non-movable version of get_user_pages() called get_user_pages_non_movable() |
| |
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? >
| |